TL;DR
- ✓Work the checklist in phases: Discovery, Authentication, Authorization, Input, Business logic, then Rate limiting.
- ✓The authorization phase is where most real bugs live. Always test BOLA and BFLA with two or more accounts.
- ✓Build a full endpoint inventory first, including old versions and hidden routes, before you test a single payload.
- ✓Map every test back to an OWASP API Security Top 10 (2023) category so your report is actionable and complete.
A good API penetration testing checklist is organized by phase, not by tool, because the order you test in determines what you find. You cannot test authorization until you have an endpoint inventory, and you cannot test business logic until you understand the auth model. This checklist walks the six phases we use on every engagement: Discovery, Authentication, Authorization, Input, Business logic, and Rate limiting.
Every item maps to the OWASP API Security Top 10 (2023) so nothing falls through the cracks. Use it as a working document, ticking items per endpoint and per role.
What does an API penetration testing checklist cover?
It covers six phases, each targeting a different class of the OWASP API Security Top 10. Discovery builds the attack surface; the auth phases catch the most damaging access-control bugs; input and logic phases catch injection and abuse; rate limiting catches resource exhaustion.
The checklist below is the short form. Each item is something you actively send a request to verify, not a box you tick from documentation. Pair it with the fundamentals of API pentesting if you are new to the discipline, and the OWASP API methodology for the why behind each test.
How do you scope and discover the API attack surface?
Start by enumerating every endpoint, version, and parameter the backend will accept, from both documented and undocumented sources. You cannot secure what you have not found, and old versions (API9, Improper Inventory Management) are a frequent foothold.
- Import the OpenAPI/Swagger spec and Postman collections. Diff documented vs live endpoints.
- Proxy the web and mobile clients through Burp Suite or mitmproxy to capture real traffic.
- Brute-force routes with
ffuf and Kiterunner against API wordlists (kr scan https://api.target.com -w routes.kite). - Hunt for old versions: try
/api/v1/ when the app uses /api/v2/, plus .json, /internal/, and /debug/ paths. - Check for exposed docs:
/swagger.json, /openapi.json, /graphql introspection.
API penetration testing checklist by phase
Discovery
- ✓Import OpenAPI/Swagger and Postman collections
- ✓Proxy web + mobile clients (Burp / mitmproxy)
- ✓Brute-force routes with ffuf / Kiterunner
- ✓Find old versions and exposed docs (API9)
Authentication (API2)
- ✓JWT: alg:none, signature strip, weak HMAC secret
- ✓Test lockout, token reuse, and expiry
- ✓Check OAuth flows and refresh-token handling
Authorization (API1 / API5)
- ✓BOLA: swap object IDs across accounts
- ✓BFLA: call admin functions as a low-priv user
- ✓Run Burp Autorize across two roles
Input (API3)
- ✓SQLi / NoSQLi on every parameter
- ✓Mass assignment of hidden fields (role, balance)
- ✓Excessive data exposure in responses
- ✓SSRF on URL/host parameters
Business logic
- ✓Tamper price, quantity, and coupon fields
- ✓Skip steps in multi-stage flows
- ✓Race concurrent requests on shared state
Rate limiting (API4)
- ✓Brute login/OTP/reset for 429 or lockout
- ✓Request oversized pages and payloads
- ✓Test GraphQL query depth and cost limits
How do you test authentication and authorization?
This is the core of any API pentest, and it requires at least two accounts and ideally two roles. Authentication tests prove who you are; authorization tests prove what you can reach. Authorization is where BOLA (API1) and BFLA (API5) live, and these are the bugs that cause the largest breaches.
For authentication, attack the token itself:
- JWT: test
alg:none, signature stripping, kid injection, and weak HMAC secrets (hashcat -m 16500 against the token). - Test for missing lockout, token reuse across services, and tokens that never expire.
For authorization, replay the same request as a different principal:
PUT /api/v1/users/501/email HTTP/1.1
Authorization: Bearer <low-priv-user-token>
Content-Type: application/json
{ "email": "attacker@evil.com" }
, - if 200, you just changed user 501's email = BOLA
Then call admin-only functions with a standard user's token (BFLA). Burp's Autorize extension automates this two-account diff. See the web app pentesting checklist for parallels in session handling.
Strobes insight
If you have time for only one phase, do authorization with two accounts. BOLA and BFLA are the most common high and critical findings on API engagements, and no automated scanner reliably catches them.
Test every parameter for injection and mass assignment, then attack the workflow itself for logic flaws. APIs trust the request body, so the property level (BOPLA, API3) is a rich target.
Input:
- SQLi and NoSQLi on every parameter, including JSON keys and headers.
- Mass assignment: add fields the client never sends, like
"role":"admin", "verified":true, or "balance":99999. - Excessive data exposure: inspect responses for fields the UI hides (hashes, internal IDs, PII).
- SSRF on any parameter that takes a URL, hostname, or file path.
Business logic:
- Replay and tamper with stateful flows: coupons, refunds, transfers, quantity and price fields.
- Skip steps in multi-stage flows (jump straight to
/checkout/confirm). - Race conditions: fire concurrent requests against a single balance or one-time token.
How do you test rate limiting and resource consumption?
Confirm that sensitive and expensive endpoints enforce throttling, pagination caps, and payload limits. Missing limits (API4, Unrestricted Resource Consumption) enable credential stuffing, enumeration, and denial of service.
- Hammer login, OTP, password-reset, and search endpoints; watch for any 429 or lockout.
- Request oversized pages:
?limit=1000000 or remove the limit entirely. - Upload large or deeply nested payloads to test parser and memory limits.
- For GraphQL, send deeply nested and aliased queries to test query-depth and cost limits.
Document every gap against its OWASP API category. For teams that want this running continuously instead of point-in-time, our AI pentesting tooling automates the repetitive discovery and rate-limit checks so testers focus on logic.
Frequently asked questions
What should be on an API penetration testing checklist?
At minimum: endpoint discovery and inventory, authentication tests (JWT and token handling), authorization tests for BOLA and BFLA across multiple accounts, input and injection tests including mass assignment, business-logic tampering, and rate-limit checks. Each item should map to an OWASP API Security Top 10 (2023) category.
How many accounts do you need for an API pentest?
At least two accounts of the same role to test BOLA, and ideally accounts of different privilege levels to test BFLA. Without a second principal you cannot prove that one user can access another user's objects or functions, which are the highest-impact findings.
What is the difference between BOLA and BFLA?
BOLA (API1) is about data: a user reaching another user's object by changing an ID. BFLA (API5) is about functionality: a low-privilege user invoking an admin or elevated function they should not have access to. Both are authorization failures, but at different levels.
How do you test JWT security in an API?
Test whether the server accepts alg:none, whether it verifies the signature at all, whether the kid header can be manipulated for key confusion, and whether a weak HMAC secret can be cracked with hashcat (mode 16500). Also check expiry, reuse, and whether claims like user_id or role can be tampered with.
How do you find hidden API endpoints?
Combine spec diffing (compare documented endpoints to live traffic), proxy capture from web and mobile clients, and route brute-forcing with ffuf or Kiterunner against API-specific wordlists. Always probe for older versions like /api/v1/ and exposed docs such as /swagger.json and /openapi.json.
Sources and references
L
Likhil Chekuri
Application Security Engineer, Strobes
Likhil Chekuri is an AppSec engineer at Strobes who has run hundreds of web, mobile, and cloud penetration tests for regulated industries.
