API pentesting: methodology, typical findings and what to prepare

How an API pentest differs from a web app pentest

An API has no screens or buttons — it has a contract: endpoints, methods, parameters, roles. So the work is built not on "click and observe" but on the specification: a complete endpoint map is built, a "which role can do what" matrix per endpoint, and that matrix is then verified with requests. Half the value of an API pentest is map completeness: vulnerabilities live in forgotten endpoints, not the visible ones.

The second difference is the weight of vulnerability classes. APIs rarely have XSS; access control reigns instead: BOLA/IDOR (access to other users' objects) is #1 in the OWASP API Security Top-10 and the most frequent finding in our projects. Injections and misconfigurations have not gone anywhere, but permissions are what earn the attacker real money.

What gets tested: along the OWASP API Security Top-10

• ◇Object-level authorization (BOLA/IDOR): every endpoint with an ID is probed under a foreign account — can another user's orders, documents, payments be read or modified.
• ◇Function-level authorization: are admin and service endpoints reachable by a regular role; the role check often exists in the UI but not in the API.
• ◇Property-level authorization (mass assignment): does the API accept extra fields — role, balance, is_verified — in create and update requests.
• ◇Authentication: token strength, revocation, lifetime, weak schemes (JWT with alg=none, predictable API keys).
• ◇Business logic: skipping process steps, race conditions (double-spending bonuses), abusing limits and promo codes.
• ◇Resources and limits: missing rate limiting and pagination — exporting the whole database through a legitimate list endpoint.
• ◇Inventory: old versions (/v1 next to /v3), test and internal endpoints exposed, spec diverging from reality.
• ◇Injections and SSRF: the classics remain — parameters, headers, file uploads, webhooks.

What to prepare before the start

An API pentest goes faster and deeper if you have: a specification (OpenAPI/Swagger; if none — a Postman collection or HAR traffic, the map can be reconstructed), a staging environment with production-like data, and accounts for every role — at least two per role, to test access to foreign objects. Without a second account per role, half of the access control checks are impossible in principle.

Staging is preferred over production: staging allows aggressive checks (races, limits, data modification) that are excluded on production or require special windows.

Manual depth + exhaustive coverage

Our approach is a combination: a manual pentest covers depth (chains, business logic, product specifics), while our own scanner Izanagi covers access control exhaustively: it walks every endpoint in the spec with attacker/victim account pairs and finds the BOLA/IDOR that selective manual testing easily misses. Every finding comes with proof: a concrete request, a concrete foreign object in the response.

Price anchor: an API pentest with a scope up to 50 endpoints — $1,900–5,000 depending on the number of roles and logic complexity. A fixed-price quote within 24 hours after a brief.

FAQ