API penetration testing: a guide to the OWASP API Security Top 10, scoping and preparation
How API penetration testing works (REST, GraphQL, gRPC): the OWASP API Security Top 10 as a coverage map, how to scope, what to hand the testers and what to expect from the report.
Summary: API penetration testing focuses on the interfaces your frontend, mobile app and partners consume — REST, GraphQL, gRPC and webhooks. The coverage reference is the OWASP API Security Top 10 (2023), led by authorization flaws that scanners cannot detect. A good API pentest is grey box: with an OpenAPI spec, per-role accounts and at least two users per role.
In modern products the API is the product. The SPA, the mobile app and the integrations are its clients, and any control that exists only in the UI can be bypassed by calling the API directly. That makes API testing the highest-return test for most software companies today.
The OWASP API Security Top 10 (2023) as a coverage map
| ID | Risk | What it means for your business |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | one customer reads another’s data by changing an identifier |
| API2 | Broken Authentication | sessions, tokens or password reset allow account takeover |
| API3 | Broken Object Property Level Authorization | fields a user should not see or change (e.g. role, price) |
| API4 | Unrestricted Resource Consumption | cost and downtime from missing limits |
| API5 | Broken Function Level Authorization | admin functions reachable by regular users |
| API6 | Unrestricted Access to Sensitive Business Flows | abusive automation of purchases, coupons, sign-ups |
| API7 | Server-Side Request Forgery | the server is tricked into reaching internal resources |
| API8 | Security Misconfiguration | CORS, headers, error messages, defaults |
| API9 | Improper Inventory Management | old versions and forgotten endpoints still live |
| API10 | Unsafe Consumption of APIs | over-trusting data from third-party APIs |
Four of the ten (API1, API3, API5, API6) are about authorization and business logic — a tool does not know what is "yours" and what is "someone else’s". The number one item is covered in BOLA/IDOR in APIs; the most common authentication mistakes in JWT and OAuth mistakes.
How to scope an API pentest
Effort depends less on the number of endpoints and more on how many object × user × operation combinations must be checked. Gather:
- Specification: OpenAPI/Swagger, GraphQL schema, .proto files, Postman collection.
- Roles and tenants: which roles exist (customer, operator, admin, partner) and whether you are multi-tenant.
- Critical flows: payments, transfers, data export, invites, email and password changes, partner integrations.
- Authentication: session, JWT, OAuth/OIDC, API keys, mTLS.
- Versions: is v1 still live? Are internal endpoints exposed through the same gateway?
- Environment: staging with realistic data, or production with an agreed window.
As a market reference, an API with up to ~80 endpoints and 2–4 roles typically takes 5–12 testing days; see how much a penetration test costs.
What to hand the testing team
- An up-to-date specification, including "internal" endpoints — undocumented ones tend to have the weakest controls.
- At least two accounts per role, across at least two tenants where relevant. Without that, horizontal authorization cannot be tested.
- Sample data in critical flows (orders, invoices, documents).
- Tester IPs allowed through the staging WAF/rate limiter, so you measure the application, not the firewall.
- A technical contact for quick questions and immediate notice of critical findings.
What to expect from the results
- Findings with a reproducible proof of concept (request and response), justified severity and business impact.
- Chains, not isolated items.
- Code- and architecture-level remediation: centralised object-level authorization, scoping in the database query, allow-listed fields in serialisation, limits per user and per business flow.
- A retest after fixes.
Preventing regressions between pentests
- Automated authorization tests in CI: two users, one object each, assert 403/404 on every endpoint.
- A living API inventory with sunset dates for old versions.
- Rate limits per user and per business flow, not just per IP.
- Security review whenever the data model or roles change.
Frequently asked questions
What is the difference between API and web application pentesting?
A web pentest covers the application as seen through the browser; an API pentest focuses on directly called interfaces, including those used by mobile apps and partners. In modern SPAs they overlap, and the ideal scope tests both layers.
Do we need to provide API documentation?
It is not mandatory but strongly recommended: without documentation part of the budget goes on discovery; with it, on attacking — and coverage goes up.
Can an API pentest run in production?
Yes, with an agreed window, load limits and clear rules for data-changing operations. When possible we prefer a staging environment that mirrors production.
Is GraphQL pentesting different?
The risk classes are the same (authorization, field exposure, resource consumption), but the surface changes: introspection, nested queries, batching and resolvers with their own authorization rules need specific technique.