TL;DR
- ✓API penetration testing assesses REST, GraphQL, and SOAP endpoints for authorization, authentication, input, and business-logic flaws an attacker can reach directly.
- ✓Most serious API bugs are authorization failures: BOLA (API1) and BFLA (API5) alone account for the majority of real breaches.
- ✓It differs from web app pentesting because there is no UI to constrain you. You attack the raw contract from a spec, proxy capture, or traffic.
- ✓Authenticated, multi-role testing is mandatory. You need at least two accounts to prove object and function-level access control gaps.
API penetration testing is a security assessment that attacks an application's APIs directly at the HTTP layer, looking for flaws in authorization, authentication, input handling, and business logic that a UI would normally hide. Because APIs expose the raw data contract, a single broken access-control check can leak every record in a table, which is why the OWASP API Security Top 10 (2023) ranks Broken Object Level Authorization (BOLA) as the number-one risk.
This guide explains what API pentesting actually covers, how a tester works through an endpoint, and how it differs from classic web application testing. If you run REST, GraphQL, or gRPC services, this is the assessment that finds the bugs scanners miss.
What is API penetration testing?
API penetration testing is the manual and automated exercise of probing an application's API endpoints for vulnerabilities an attacker could exploit without going through the front-end UI. You work against the raw request and response: forging object IDs, swapping tokens between accounts, sending fields the client never shows, and abusing endpoints that lack rate limits.
The work is structured around the OWASP API Security Top 10, which names the risk classes you test against:
- API1 BOLA: changing an object identifier to read or modify another user's data.
- API2 Broken Authentication: weak JWT validation, guessable tokens, no lockout.
- API3 BOPLA: mass assignment and excessive data exposure at the property level.
- API4 Unrestricted Resource Consumption: missing rate limits and pagination caps.
- API5 BFLA: a standard user reaching admin-only functions.
Unlike a vulnerability scan, an API pentest reasons about authorization context. A scanner cannot know that GET /api/v1/orders/1043 belongs to a different tenant. A tester with two accounts can prove it.
API pentest vs web app pentest
| Aspect | API pentest | Web app pentest |
|---|
| Entry point | OpenAPI / Postman / captured traffic | Rendered UI and crawled pages |
| Top risk class | Broken authorization (BOLA / BFLA) | Injection and XSS |
| Accounts needed | Two or more roles, mandatory | Often single account |
| Framework | OWASP API Top 10 (2023) | OWASP WSTG / Top 10 |
How does API penetration testing differ from web app testing?
The core difference is that an API has no UI to limit what you send, so the attack surface is the documented (and undocumented) contract itself. In a web application pentest you often discover functionality by crawling rendered pages. With an API you start from an OpenAPI/Swagger spec, a Postman collection, a GraphQL introspection dump, or captured mobile traffic, then test every parameter the backend will accept.
Three practical consequences follow:
- Authorization bugs dominate. There is no server-rendered template enforcing what you see, so object and function-level checks are the whole game.
- State and sequence matter. Many API flaws are business-logic issues: replaying a coupon, skipping a payment step, racing two requests against one balance.
- Hidden versions and endpoints are common.
/api/v1/ may be deprecated but still live alongside /api/v2/, with weaker auth on the old path (OWASP API9, Improper Inventory Management).
What vulnerabilities does an API pentest find?
The highest-impact findings are almost always broken authorization. The classic BOLA case looks like this: you authenticate as user A, capture a request, and increment the object ID.
GET /api/v1/accounts/2001/statements HTTP/1.1
Host: bank.example.com
Authorization: Bearer <user-A-token>
, - response , -
200 OK
{ "account": 2001, "owner": "userB@example.com", "balance": 84210.55 }
User A's token returned user B's statement. That is a BOLA, and it is exploitable at scale by iterating the ID. Beyond that, a pentest commonly surfaces:
- Mass assignment (BOPLA): adding
"role":"admin" or "isVerified":true to a profile-update body the API blindly binds. - JWT weaknesses:
alg:none accepted, signature not verified, or secrets brute-forceable with hashcat. - Excessive data exposure: an endpoint returning full user objects (password hashes, internal flags) and relying on the client to hide fields.
- Missing rate limits: OTP and login endpoints with no throttling, enabling credential stuffing and enumeration.
Strobes insight
Broken Object Level Authorization (API1) shows up in roughly 4 of every 5 API engagements we run. If you only test one thing, test whether one user's token can reach another user's objects.
You start by building a complete endpoint inventory, then attack each endpoint by authorization context, input, and logic. A typical flow:
- Discovery. Import the OpenAPI/Swagger or Postman collection, run introspection on GraphQL, or proxy the mobile app through Burp Suite. Fuzz for hidden routes with ffuf or Kiterunner against an API wordlist.
- AuthN/AuthZ. Set up at least two accounts (and roles). Replay each request with the other account's token to test BOLA, and call admin functions as a low-priv user to test BFLA.
- Input and injection. Test every parameter for SQLi, NoSQLi, SSRF, and mass assignment. Schemathesis can auto-generate test cases from the spec.
- Business logic. Probe sequencing, replay, and race conditions on stateful flows like checkout or transfers.
- Resource consumption. Remove rate limits, request huge page sizes, and nest GraphQL queries to test for denial of service.
For the full sequence, see our API penetration testing checklist and the tools we use for each phase. Running this continuously rather than once a year is where agentic pentesting changes the economics.
Why does API security matter now?
APIs are the primary attack surface for modern apps because nearly every mobile, single-page, and partner integration runs on them, and they carry the data directly. A broken authorization check on one endpoint can expose an entire customer base, and these flaws are invisible to network scanners and most DAST tools.
The economics favor attackers too. Object IDs are usually sequential integers, tokens are often reused across services, and old API versions linger after a rewrite. Testing the API contract directly, with multiple authenticated roles, is the only reliable way to catch these issues before they become a disclosure event.
Frequently asked questions
What is the difference between API testing and API penetration testing?
API testing usually means functional or performance testing: does the endpoint return the right data quickly. API penetration testing is adversarial. It tries to break authorization, authentication, and business logic to access data or functions you should not be able to reach.
What is BOLA in API security?
BOLA stands for Broken Object Level Authorization, the top risk in the OWASP API Security Top 10 (2023). It happens when an API uses an object ID from the request to fetch data without checking the caller actually owns that object, letting an attacker read or modify other users' records by changing the ID.
Can API penetration testing be automated?
Parts of it can. Tools like Schemathesis, ffuf, and Burp Suite automate discovery, fuzzing, and spec-driven testing. But authorization and business-logic flaws require a human (or an agentic system) reasoning about who owns what, so the highest-value findings still need manual or AI-driven testing.
What tools are used for API penetration testing?
Common tools include Burp Suite and mitmproxy for interception, Postman for replay, ffuf and Kiterunner for endpoint discovery, Schemathesis for spec-based fuzzing, and jwt_tool for token attacks. GraphQL adds InQL, Clairvoyance, and graphw00f.
How long does an API penetration test take?
A focused REST API with 20 to 40 endpoints typically takes 3 to 5 days of testing. Larger surfaces with many roles, GraphQL introspection, and complex business logic can run 2 weeks or more. Scope is driven by endpoint count, number of roles, and depth of stateful workflows.
Is API penetration testing required for compliance?
It is increasingly expected under PCI DSS, SOC 2, and similar frameworks that require testing of in-scope applications. APIs that handle cardholder or regulated data fall within those testing requirements even when they have no UI.
Sources and references
S
Shubham Jha
Security Researcher, Strobes
Shubham Jha leads offensive security research at Strobes, focused on web and API exploitation and red team tradecraft.
