API Security Testing in 2026: The OWASP API Top 10 and What Actually Gets Missed
A majority of organizations have already experienced an API security incident, and yet API testing maturity still lags behind how fast teams ship new endpoints. Part of the gap is structural: the vulnerability class that causes the most damage — broken authorization — is exactly the one automated scanners are worst at finding.
Why APIs fail differently than web apps
A web application has a UI standing between a user and the backend, which — intentionally or not — hides a lot of what's possible. An API has no such layer. Every parameter, every object ID, every role check is directly exposed to whoever can craft a request, which means every one of those is also directly exposed to anyone probing for a gap. APIs also tend to multiply faster than anyone tracks: a mobile app, a partner integration, and an internal admin tool might all hit variations of the same backend through endpoints nobody inventoried together.
The OWASP API Security Top 10, briefly
| # | Risk | What it means in practice |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | Changing an ID in a request returns someone else's data |
| API2 | Broken Authentication | Weak token handling, credential stuffing, missing MFA on API auth flows |
| API3 | Broken Object Property Level Authorization | Can read/write fields on an object you shouldn't touch (e.g. "isAdmin") |
| API4 | Unrestricted Resource Consumption | No rate limiting — an endpoint can be abused for cost or denial-of-service |
| API5 | Broken Function Level Authorization | A regular user can call an admin-only endpoint directly |
| API6 | Unrestricted Access to Sensitive Business Flows | Automatable abuse of a legitimate flow (e.g. bulk account creation, scalping) |
| API7 | Server Side Request Forgery (SSRF) | API fetches a URL you control, reaching internal services |
| API8 | Security Misconfiguration | Verbose errors, missing security headers, permissive CORS |
| API9 | Improper Inventory Management | Old or undocumented API versions left running, untested |
| API10 | Unsafe Consumption of APIs | Trusting data from a third-party API without validating it |
Why BOLA keeps topping the list
Broken Object Level Authorization has held the #1 spot for years for a simple reason: it's everywhere, it's trivial to exploit once found, and it's genuinely hard for a scanner to catch on its own. A BOLA check requires testing with two separate authenticated identities — does User A's token let you fetch User B's invoice by just changing an order ID? — not just scanning one account's access with one token. Most automated DAST tools authenticate as a single user and never make that comparison, which is exactly why this keeps showing up in real-world breach writeups years after it was first called out as the top API risk.
Broken Function Level Authorization (API5) is BOLA's close cousin and gets missed for the same structural reason: it's a question about what a role is allowed to do, which requires the tester to know the intended authorization model, not just send traffic and watch for errors.
"A scanner can tell you the endpoint returned 200. It can't tell you it should have returned 403."
GraphQL adds its own set of problems
REST isn't the only API shape that matters anymore. GraphQL introduces risks that don't map cleanly onto the OWASP list above: overly permissive introspection that hands an attacker the entire schema on request, deeply nested or recursive queries used to exhaust server resources, and authorization logic that's correctly enforced on one query path to a piece of data but accidentally skipped on an alternate path that reaches the same underlying object. Testing GraphQL properly means testing the schema itself, not just a handful of sample queries.
What good API testing actually looks like
Starting from a current API inventory — not the one from the last annual pentest, the one that reflects what's actually deployed right now, including internal and partner-facing endpoints that never made it into public docs. From there: authentication and session handling, object- and function-level authorization tested across multiple identities and roles, input validation and injection testing per endpoint, rate-limiting and resource-consumption checks, and a specific pass for SSRF wherever the API fetches a URL or resource on the caller's behalf.
ComplyArmor's Smart PTaaS treats API security testing as one of our nine attack surfaces — autonomous discovery maps the live endpoint inventory continuously, and every authorization finding, including multi-identity BOLA testing, is manually verified by a human tester before it reaches your report. See our methodology for how autonomous discovery and expert verification fit together.
Frequently asked questions
What is API security testing?
API security testing is penetration testing focused specifically on APIs (REST, GraphQL, SOAP, gRPC) rather than the web or mobile front-end that calls them — testing authentication and authorization logic, object-level access control, rate limiting, input validation, and business logic for each endpoint and parameter, often guided by the OWASP API Security Top 10.
What is BOLA and why does it matter so much for APIs?
BOLA (Broken Object Level Authorization) is when an API lets an authenticated user access or modify an object — another user's order, invoice, or profile — simply by changing an ID in the request, without checking that the requester actually owns that object. It's been the #1 item on the OWASP API Security Top 10 for years because it's extremely common, easy to exploit, and routinely missed by automated scanners since detecting it requires testing with two different authenticated identities, not just one.
Can automated tools fully test API security?
No. Automated scanners are good at catching missing security headers, verbose error messages, and some injection flaws, but authorization logic flaws like BOLA and broken function-level authorization require a tester to understand what a user is supposed to be allowed to do, then deliberately try to do something else as a different identity. That's a judgment call a scanner can't make on its own.
Does API security testing cover GraphQL?
It should. GraphQL introduces its own set of risks beyond the standard REST concerns — overly permissive introspection that exposes the entire schema, deeply nested queries used for denial-of-service, and authorization checks that are correctly applied to one query path but missed on an alternate path to the same underlying data.
How often should APIs be tested?
Continuously, ideally — APIs change with every deployment, and a new endpoint or parameter shipped without the same authorization checks as the rest of the API is a common way access-control gaps get introduced. An annual test only catches what existed on the day it ran; anything shipped the week after is untested until the next cycle.
If your API inventory hasn't been re-checked since your last pentest, that gap is worth closing before an attacker finds it for you.