APIs now carry most of the data that moves between your product, your mobile apps, your partners and your customers. They are also where many of today's most damaging data exposures begin — usually not through exotic exploits, but through simple authorization mistakes that let one user read or change another user's data. This guide explains what an API penetration test covers, how it differs from a web app test, and how to prepare so the testers spend their time finding real issues.
What is API penetration testing?
An API penetration test is a manual, adversarial assessment of your REST, GraphQL, gRPC or SOAP interfaces. Testers authenticate as different users and roles, map every endpoint and parameter, and attempt to break authentication, authorization, input handling and business rules. Unlike a web application test, there is often no user interface to guide discovery — testers work from documentation (OpenAPI/Swagger, Postman collections, GraphQL schemas) and from traffic captured from your clients.
The OWASP API Security Top 10 (2023)
The OWASP API Security Top 10 is the most widely used reference for API testing. Every competent API pentest should cover all ten categories:
| ID | Risk | What testers try |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | Changing object IDs in requests to access other users' records |
| API2 | Broken Authentication | Weak token handling, credential stuffing, JWT flaws, missing rate limits on login |
| API3 | Broken Object Property Level Authorization | Reading hidden fields (excessive data exposure) or writing protected ones (mass assignment) |
| API4 | Unrestricted Resource Consumption | Missing limits on request size, pagination, uploads or costly operations |
| API5 | Broken Function Level Authorization | Calling admin-only endpoints as a regular user |
| API6 | Unrestricted Access to Sensitive Business Flows | Automating flows like sign-ups, purchases or coupon redemption at abusive scale |
| API7 | Server-Side Request Forgery (SSRF) | Making the server fetch internal URLs, cloud metadata endpoints |
| API8 | Security Misconfiguration | Verbose errors, permissive CORS, missing TLS, debug endpoints |
| API9 | Improper Inventory Management | Finding old API versions, staging hosts and undocumented endpoints |
| API10 | Unsafe Consumption of APIs | Abusing trust in data returned by third-party APIs you integrate with |
Notice how many of these are about authorization. Automated scanners can't know that user A shouldn't see invoice 1043 — only a tester who understands your data model can. That is why the manual share of an API test matters so much.
API pentest vs. web application pentest
| Web application test | API test | |
|---|---|---|
| Discovery | Crawling the UI | Docs, schemas, client traffic, version enumeration |
| Main risks | XSS, CSRF, session issues, plus server-side flaws | Authorization, mass assignment, rate limits, data exposure |
| Tooling | Browser + intercepting proxy | Proxy, Postman/Insomnia, GraphQL tools, custom scripts |
| Scope driver | Pages, roles, workflows | Endpoints, methods, roles, tenants |
Most products need both, and testing them together in one engagement is usually cheaper than two separate tests.
GraphQL-specific testing
GraphQL APIs deserve special attention because a single endpoint exposes the entire data graph. Good testers check whether introspection is exposed in production, whether resolvers enforce authorization on every field and nested object, whether query depth and complexity limits exist, and whether batching or aliasing can be used to bypass rate limits (for example, trying many one-time codes in one request).
How to prepare for an API penetration test
- Provide an up-to-date OpenAPI/Swagger file, Postman collection or GraphQL schema
- Create at least two accounts per role and, for SaaS, accounts in two separate tenants — this is essential for BOLA testing
- Share sample object IDs and explain your ID scheme (sequential, UUID, etc.)
- List all API versions and hosts still reachable, including legacy ones
- Explain rate limits and any WAF so testers can be allow-listed where appropriate
- Flag destructive endpoints (payments, deletions, emails to real users) and provide safe test data
How API tests are scoped and priced
Vendors usually estimate effort from the number of endpoints × methods × roles. As a rough guide, 20–50 endpoints with three roles typically takes 4–8 tester-days. Large APIs with hundreds of endpoints are often sampled by risk, focusing on endpoints that handle money, personal data, authentication and administration. Typical market pricing is covered in our pricing guide.
What a good API test report includes
- The full request and response for each finding, so developers can reproduce it in minutes
- Which roles and tenants were tested and which endpoints were covered
- Root-cause remediation (e.g., "enforce ownership checks in the data-access layer"), not just "validate input"
- Mapping to OWASP API Top 10 categories
Frequently asked questions
Can automated scanners test APIs effectively?
Scanners help with injection and misconfiguration, but they cannot judge whether a user should access a given object or function. Authorization flaws — the top API risks — need manual testing.
Do we need API documentation for a pentest?
It is strongly recommended. OpenAPI files, Postman collections or GraphQL schemas let testers cover every endpoint instead of spending paid time on discovery.
Should internal APIs be tested?
Yes, if they handle sensitive data or could be reached after a compromise. Many breaches pivot through internal APIs that assumed callers were trusted.
See our API penetration testing service, or request an API pentest quote.