On this page
- Before you start: scoping an API test
- The OWASP API Security Top 10 checklist
- API1: Broken Object Level Authorization (BOLA)
- API2: Broken Authentication
- API3: Broken Object Property Level Authorization
- API4: Unrestricted Resource Consumption
- API5: Broken Function Level Authorization
- API6: Unrestricted Access to Sensitive Business Flows
- API7: Server Side Request Forgery (SSRF)
- API8: Security Misconfiguration
- API9: Improper Inventory Management
- API10: Unsafe Consumption of APIs
- Beyond the Top 10
- What a good API pentest report shows
- How Summit tests APIs
- Frequently asked questions
APIs carry most of the data in modern applications, and they are often less protected than the screens built on top of them. A mobile app may show a user only their own orders while the API behind it returns anyone’s order to anyone who asks. This checklist is what our testers work through on every API security test.
Before you start: scoping an API test
- Get the inventory. OpenAPI or Swagger files, Postman collections, GraphQL schemas and any internal or partner APIs. Ask what is missing from the docs.
- Create test accounts for every role, and at least two users per role in two different tenants. Authorisation testing is impossible without them.
- Choose the environment. A staging environment that mirrors production, with realistic data, so destructive tests do not touch customers.
- Agree limits. Rate-limit and denial-of-service testing, email or SMS triggers, payments and third-party calls need explicit rules.
- Name a contact who can reset accounts and unblock the tester quickly.
The OWASP API Security Top 10 checklist
API1: Broken Object Level Authorization (BOLA)
- Swap object IDs (numeric, UUID, slugs) between two users and two tenants on every endpoint that takes an ID
- Test IDs in paths, query strings, request bodies, headers and GraphQL arguments
- Check bulk and export endpoints, which often skip per-object checks
- Try predictable or leaked IDs from other responses, emails or URLs
Our IDOR case study shows what a single BOLA flaw can expose.
API2: Broken Authentication
- Test login, token refresh, password reset and MFA flows for bypasses and brute-force protection
- Check JWT handling: signature verification, algorithm confusion, expiry, audience and key rotation
- Confirm tokens are revoked on logout and password change
- Look for API keys in mobile apps, front-end code and public repositories
API3: Broken Object Property Level Authorization
- Look for responses that return more fields than the client displays, such as internal flags, other users’ emails or hashed passwords
- Test mass assignment: add fields such as
role,isAdmin,tenantIdorpriceto update requests - Compare responses between roles for the same object
API4: Unrestricted Resource Consumption
- Check rate limits on login, OTP, search, export and expensive endpoints
- Test large page sizes, deep pagination, large uploads and batch requests
- For GraphQL, test query depth, aliasing and batching limits
- Look for endpoints that trigger paid actions such as SMS, email or third-party calls
API5: Broken Function Level Authorization
- Call admin and internal endpoints with a regular user’s token
- Change HTTP methods (GET to PUT or DELETE) on endpoints the user can read
- Look for hidden admin routes in documentation, JavaScript bundles and mobile apps
API6: Unrestricted Access to Sensitive Business Flows
- Identify flows that are valuable to abuse at scale: signups, referrals, coupons, bookings, purchases
- Test whether they can be automated without limits, skipped out of order or replayed
- Check that steps such as payment or approval cannot be bypassed by calling the final endpoint directly
API7: Server Side Request Forgery (SSRF)
- Find parameters that accept URLs: webhooks, file imports, image fetchers, PDF generators
- Test access to internal addresses and cloud metadata services
- Check redirect following and alternative URL encodings
API8: Security Misconfiguration
- Check CORS policy, security headers, verbose errors and stack traces
- Confirm TLS everywhere, including internal service-to-service calls where in scope
- Look for debug endpoints, default credentials and unnecessary HTTP methods
See our guide to CORS misconfiguration for one of the most common findings.
API9: Improper Inventory Management
- Look for old API versions (
/v1/alongside/v3/) that still work with weaker controls - Find staging, beta or test hosts exposed to the internet
- Compare the documented endpoints with what the application actually calls
API10: Unsafe Consumption of APIs
- Check how your API treats data from third-party APIs: is it validated and sanitised?
- Test whether redirects or responses from partners are followed blindly
- Confirm integrations use TLS and verify certificates
Beyond the Top 10
- Injection in all its forms: SQL, NoSQL, command and template injection
- File upload handling: type checks, storage location and malware handling
- Sensitive data in logs, error messages and analytics calls
- Webhooks: signature verification and replay protection
- Multi-tenant isolation at the database and cache layer
- GraphQL introspection and field-level authorisation
What a good API pentest report shows
Each finding should name the endpoint and method, the roles involved, the exact request and response that prove the issue, the business impact (for example “any customer can download any other customer’s invoices”), a specific fix and a severity your engineers can prioritise with. The report should also list what was tested and found secure, so auditors and customers can see the coverage. Read what makes a VAPT report worth paying for.
How Summit tests APIs
Summit’s API security testing is manual and role-based: our testers work through every endpoint with real accounts for each role and tenant, map findings to the OWASP API Security Top 10, and retest after you fix. We test REST, GraphQL and the APIs behind mobile apps and web applications, and our reports support SOC 2, ISO 27001, PCI DSS and customer security reviews.
Want your API tested by hand?
Send us your API documentation and we will scope a test within a day. Get a quote.
Related reading: Mobile app penetration testing checklist · Web application VAPT guide · PCI DSS penetration testing requirements
Frequently asked questions
What is API penetration testing?
A manual security test of an application programming interface in which a tester tries to break authentication, access other users' data, abuse business flows and exploit misconfigurations, the way a real attacker would. It goes beyond automated scanning by testing authorisation and logic with real user roles.
What is the OWASP API Security Top 10?
A list of the ten most critical API security risks published by OWASP. The current edition, from 2023, covers broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management and unsafe consumption of APIs.
What is the most common API vulnerability?
Broken object level authorization (BOLA, also called IDOR), where changing an ID in a request returns another user's or tenant's data. It is first on the OWASP API list because it is common, easy to exploit and often exposes large amounts of data.
How long does an API penetration test take?
A single API with a few dozen endpoints typically needs three to seven working days of testing, plus reporting and a retest. Large APIs, multiple roles or GraphQL schemas take longer.
What do I need to provide for an API penetration test?
API documentation such as an OpenAPI or Postman collection, a test environment that mirrors production, test accounts for each role and at least two tenants or users per role, and a contact who can unblock issues during testing.
Can automated scanners replace API penetration testing?
No. Scanners find missing headers and known misconfigurations, but they cannot tell whether user A should be allowed to read user B's invoice. Authorisation and business logic flaws, the most damaging API issues, need a human tester.
