A web application penetration test does not cover the API behind it. Scanners find endpoints by crawling links, and APIs have no links to crawl. The result is that most organisations who believe they have tested their application have tested the part a browser renders and left the part that actually moves data untested.
This matters more each year because the architecture moved. Single-page apps, mobile clients and partner integrations all talk to the same API, and that API often exposes more than the UI ever calls. This guide covers what API penetration testing actually finds, why the OWASP API Security Top 10 is a separate list from the main one, and how to scope it properly.
Why Scanners Cannot Find the Biggest API Risk
The top API risk is Broken Object Level Authorization — BOLA. It has held the number one position on every OWASP API list since 2019 and accounts for roughly 40% of API attacks.
BOLA is simple to describe: an API accepts an object ID and returns the object without checking whether the caller is entitled to it. Change 1024 to 1025 in the request and you get someone else's order, invoice or medical record.
This is why it survives automated testing. The response is a clean 200 with valid JSON. Nothing is malformed, nothing errors, no signature matches. A scanner has no way of knowing that record 1024 belongs to a different customer — that requires understanding what your data means and who is supposed to see it.
The same limitation applies to a WAF. It inspects the request without knowing whether the caller owns object 1024. These tools are necessary and they are not sufficient.
The OWASP API Security Top 10 Is a Separate List
Teams often assume the main OWASP list covers APIs. It does not, in the specific sense that matters — OWASP maintains a dedicated API list because API risks concentrate differently.
The current edition is OWASP API Security Top 10:2023, introduced in 2019 and last updated in 2023:
| ID | Risk |
|---|---|
| API1:2023 | Broken Object Level Authorization (BOLA) |
| API2:2023 | Broken Authentication |
| API3:2023 | Broken Object Property Level Authorization (BOPLA) |
| API4:2023 | Unrestricted Resource Consumption |
| API5:2023 | Broken Function Level Authorization (BFLA) |
| API6:2023 | Unrestricted Access to Sensitive Business Flows |
| API7:2023 | Server Side Request Forgery (SSRF) |
| API8:2023 | Security Misconfiguration |
| API9:2023 | Improper Inventory Management |
| API10:2023 | Unsafe Consumption of APIs |
Four of the top five are authorisation failures. BOLA and BFLA have held their positions since 2019. Injection and logging dropped off the list entirely — not because they stopped mattering, but because authorisation now dominates how APIs actually get breached.
An interesting divergence worth knowing: the 2023 API list gives SSRF its own slot at API7, while the main OWASP Top 10:2025 folded SSRF into A01 Broken Access Control. The two lists evolve independently and on different cycles.
What API Testing Finds That Web Testing Does Not
- Object-level authorisation across every endpoint. A tester with two accounts systematically tries to reach account A's data using account B's token. There is no shortcut for this.
- Function-level authorisation (BFLA). Can a standard user call the admin endpoint by guessing the path or changing the HTTP method? The UI never offers the button; the API still answers.
- Over-exposed properties (BOPLA). Endpoints frequently return more fields than the interface displays — internal flags, cost prices, other users' identifiers. Nobody notices because the frontend filters them.
- Shadow and zombie endpoints. Improper Inventory Management is API9 for good reason. Old versions left running, staging endpoints reachable from the internet, and undocumented routes are common findings and never appear in the specification.
- Business flow abuse. An endpoint that works correctly for one call can be abused at scale — bulk enumeration, automated purchasing, credential testing. This is API6, and it needs someone thinking about your business rather than your code.
GraphQL Needs Its Own Treatment
GraphQL collapses many endpoints into one, which changes the testing shape entirely. Introspection may expose the whole schema. Deeply nested queries can exhaust resources — a variant of API4. And authorisation has to be enforced per field and per object, not per route, which is a materially harder thing to get right.
If you run GraphQL, confirm your provider has tested it before. Applying REST methodology to a GraphQL endpoint produces a thin report.
Scoping API Testing Properly
The questions that determine whether the test is worth anything:
- Have you provided an inventory? Give the tester your OpenAPI or GraphQL schema, plus anything not in it. If you cannot produce an inventory, that is itself the first finding.
- Are there at least two test accounts? BOLA cannot be tested with one. The tester needs account A and account B, ideally with different roles.
- Are internal and partner APIs in scope? Service-to-service APIs frequently assume the network is trustworthy. That assumption fails the moment anything upstream is compromised.
- Are all versions included? Testing v3 while v1 remains live and unauthenticated is a common and expensive gap.
Our guide to what a VAPT audit covers walks through how these phases run in practice, and what it costs sets out how scope affects price — API testing typically adds to a web application engagement rather than being included in it.
Where This Sits for Regulated Buyers
For Indian fintechs, API coverage is not optional. RBI's expectations explicitly require VAPT scope to cover applications, infrastructure and APIs — a point covered in our guide to VAPT for RBI compliance. Under SOC 2 and ISO 27001, an auditor assessing access control will reasonably ask whether the API was in scope, since that is where the authorisation model actually lives.
What to Fix Before Testing
Two things reduce findings cheaply and should happen in the pipeline rather than after a report:
Build an inventory and keep it generated. You cannot secure endpoints you cannot see. Generate and lint an OpenAPI specification as part of CI so shadow endpoints cannot appear silently.
Enforce authorisation centrally. BOLA persists because per-object checks get implemented endpoint by endpoint and one gets missed. A shared authorisation layer that every handler must pass through turns a recurring class of bug into a single place to get right. That is DevSecOps work, and it is why teams with mature pipelines see the same finding fewer times.
Getting API Testing Scoped
If your last penetration test covered a web application and you are not certain the API behind it was in scope, it probably was not. That is worth checking before your next customer security review asks.
To have your APIs assessed properly — with real accounts, full inventory and the authorisation testing that scanners cannot do — explore our VAPT services or talk to our team. We will scope the API surface separately from the application, because they are different tests.
Related reading: how to choose a VAPT company and our cloud security services for the continuous controls that sit underneath.
