← Back to blog

API Penetration Testing: A Practical Checklist

NIMR Security Team
API securitypenetration testingOWASP

APIs are the attack surface attackers hit first. While web UI testing is well understood, API testing has its own set of traps: broken object-level authorization, mass assignment, and business logic that no scanner will ever find.

This checklist reflects how we actually scope and run API assessments at NIMR.

1. Start with enumeration, not exploitation

Before touching a single endpoint, map the surface:

  • Collect every host, subdomain, and API base URL in scope
  • Pull OpenAPI/Swagger specs, GraphQL schemas, and Postman collections
  • Enumerate versions (/api/v1, /api/v2) and staging environments
  • Document authentication requirements per endpoint

2. Attack authentication and authorization

  • Test for broken object-level authorization (BOLA) by swapping IDs across accounts
  • Check broken function-level authorization (BFLA) on admin endpoints
  • Verify refresh-token rotation and session invalidation on logout
  • Probe for JWT weaknesses: alg=none, weak signing keys, missing exp
CheckWhat to look for
BOLA / IDORDirect object references return other users' data
BFLARegular tokens reach admin-only routes
Rate limitingUnlimited login or OTP attempts
Input validationMass assignment on PATCH and POST bodies

3. Business logic is the real target

Scanners miss logic flaws. Think like the product owner:

  • Can an order be placed at a negative price?
  • Can quantity, currency, or discount fields be tampered with?
  • Does applying a coupon twice stack the discount?
  • Are state transitions enforced (draft → review → published)?
{
  "product_id": "p-104",
  "quantity": -5,
  "price": 0.01
}

If the API accepts the payload above without complaint, you've found a logic bug worth reporting at high severity.

4. Data exposure and leakage

  • Do error messages leak stack traces, SQL fragments, or tokens?
  • Are verbose responses returning more fields than the client needs?
  • Check pagination for cross-tenant data leakage
  • Inspect response headers for Server, X-Powered-By, and debug flags

5. Report with reproduction, not just findings

A useful report includes the request/response pair, a clean reproduction sequence, business impact, and a concrete remediation. Every finding should be answerable by the development team within a day of triage.

Want this run against your environment? NIMR's web & API VAPT covers the OWASP API Top 10 with manual testing on top of automated scanning.