The defects that matter most in an API are all the same shape of question: can this caller reach what that caller owns. None of them can be answered from a single account, because a single account cannot be compared against anything. So the assessment starts by building an authorisation matrix from your roles, and then tests every route against it.
What a run returns
Read from what B-52 returns on API engagements. The first two rows are the two that a gateway cannot see and a scanner cannot reach.
| Class | What it looks like on a real API |
|---|---|
| Broken object level authorisation | An identifier changed in a request that the server honours, so one account reads another account’s records. The response is well formed, the status is 200, and nothing in the exchange looks anomalous. It is the first entry on the API list and the most expensive one to have missed. |
| Broken authentication | A gateway that accepts an operation with no session at all, a flow that issues a token to the wrong party, or a route into the service that does not pass the front door the front door believes it controls. |
| Token issuance and verification | What the service will sign, what it will accept, and whether the claims inside a token are checked against anything at all before they are trusted. |
| Object property level authorisation | A field returned to a caller who should not see it, or accepted on input and written when it should have been ignored. Two sides of one defect, and both stay invisible unless the properties are compared role against role. |
| Function level authorisation | An administrative operation reachable by a role the interface never offers it to — usually found because the specification names it, or because a client that calls it does. |
| Undocumented and superseded routes | Versions still answering long after the client moved on, and operations that never appeared in a specification at all. Both are in scope because both are reachable. |
| Configuration at the edge | What the gateway accepts across origins, which headers it forwards, and what it does with a request that was not in the shape anybody designed for. |
| Sensitive business flows | An operation that is individually authorised and collectively abusable — the one the rate limit existed to cover, tested by sequence rather than by volume. |
Broken object level authorisation
Broken authentication
Token issuance and verification
Object property level authorisation
Function level authorisation
Undocumented and superseded routes
Configuration at the edge
Sensitive business flows
Why one credential is not enough
Object level, function level and property level authorisation are the same question asked about three different things: can this caller reach what that caller owns. Not one of them can be answered from a single account, because a single account has nothing to be compared against. A scope with one credential in it therefore returns the parts of the list a pattern can match and leaves the top of the list untested — which is why the credential set is agreed before a run rather than assembled during one. Where the API has three roles that matter, the assessment wants three.
Class and boundary
The dividing line is consumers. An interface with one front end is part of that front end’s assessment; an interface with several is a product with its own boundary.
The operations the service exposes, the authentication and session handling in front of them, the authorisation decision behind each, and what each route returns and accepts once the caller’s role is taken into account.
A browser or mobile client in front of the API is its own class. Where the API exists only to serve that one front end, it is worked inside that assessment rather than scoped separately.
AdjacentWhere the API sits behind a managed gateway, the gateway’s policy and identity configuration is as much cloud work as API work, and the two run together rather than reporting the same thing twice.
Out of scope for the platform entirely, in every class. It is the only exclusion, and it is stated the same way everywhere on this site.
Who this page is for
Both are answered here. Where they should start is not the same.
By phase
The phase names are the platform’s. The one that changes most on this class is planning, because that is where the matrix everything else is tested against gets written.
| Phase | What enters | What leaves |
|---|---|---|
| Discovery | A base URL, a specification where a current one exists, and a credential for each role. | The routes that actually answer — from the specification, from the clients that call the service, and from what responds when the specification turns out to be a release behind. |
| Planning | The route set, and the roles. | An authorisation matrix: which role should reach which operation and which object, written down before anything is tested against it. A finding is a disagreement with this document. |
| Scanning | The route set. | Candidates. Nothing leaves this phase as a finding, and nothing is reported from it. |
| Exploitation | A candidate, and a second credential to test it with. | A finding where one role reached what another owns, and a drop where the boundary held. Both are established by making the request rather than by reading the code that answers it. |
| Reporting | Confirmed findings. | The two requests and the two responses that prove the difference, landing in your dashboard as each is confirmed. |
| QA | The finished report. | A gate that can send it back to reporting before you see it. It is where a route that answered is separated from a route that leaked. |
Discovery
Planning
Scanning
Exploitation
Reporting
QA
On the specification
Where a current specification exists it is a good starting point and it shortens discovery considerably. It is not the inventory, because a specification describes what the team believes it published, and an assessment has to work from what the service answers to. The gap between those two is where the superseded versions live, and the internal operations that were never meant to be reachable, and the route somebody added in a hurry. So the specification is read, and then discovery goes and asks.
The boundary
Three actions need your written approval on every coverage class. On this one it is the first that comes up constantly, because proving a defect and changing your data are one keystroke apart.
| State | What it means | What follows |
|---|---|---|
| Destructive or state-changing operations | Anything that creates, alters or removes a record in a live system, rather than demonstrating that it could be. On an interface built for writes, that is most of the surface. | Stops and waits, in writing. |
| Reading another account’s real data | Proving that one role reaches another role’s object takes one record. Enumerating the rest of them is a separate act with a separate answer. | Stops and waits, in writing. |
| Persistence and movement past the entry host | Where a finding yields a foothold on the infrastructure behind the interface, going further is an internal network question rather than an API one. | Stops and waits, in writing. |
| Everything else inside the authorised scope Terminal | Discovery, matrix construction, scanning, read-side exploitation, chaining and reporting. | Runs without asking. |
A practical consequence
An authorisation defect on a write operation is cleanest to prove by performing the write, and on a production system that is the first gate. The result is that a production-only scope answers the read side of the list fully and the write side under a standing constraint. Where a staging environment exists with the same enforcement and the same roles, providing it removes that constraint entirely. Where it does not, the scope says so and the report says which findings were established rather than performed — the alternative being a report that quietly understates half the surface.
Methodology
The first row is the one people get wrong, and the row note explains which way the mistake runs.
| Standard | Version | What it carries here |
|---|---|---|
| OWASP API Security Top 10 | 2023 edition. Read 2026-09-13 | The category each finding is reported under. Its first entries are authorisation failures, which is what makes the credential set the decision that most changes an assessment. |
| Still current: 2023 is the only major update since 2019, and there is no 2025 or 2026 edition. The OWASP web Top 10 did move to a 2025 edition — citing a matching year here would cite a document that does not exist. | ||
| OWASP ASVS | 5.0.0, May 2025. 17 categories | The verification requirement a finding is mapped to, and the level a scope is agreed against. |
| The first major release in six years; 4.0.3 is superseded. | ||
| OWASP WSTG | v4.2, the current stable release | The test procedures for everything an API shares with a web application — session handling, input handling, transport. |
| v5.0 is in development and is not cited here until it is stable. | ||
| CVSS | v4.0, November 2023. Read 2026-09-13 | The severity vector on every finding, so your team can recompute against its own environmental metrics instead of taking ours. |
OWASP API Security Top 10
Still current: 2023 is the only major update since 2019, and there is no 2025 or 2026 edition. The OWASP web Top 10 did move to a 2025 edition — citing a matching year here would cite a document that does not exist.
OWASP ASVS
The first major release in six years; 4.0.3 is superseded.
OWASP WSTG
v5.0 is in development and is not cited here until it is stable.
CVSS
Before a run starts
Deliberately excluded
Per finding
The request that should have worked and the request that should not, with both responses beside each other. One request on its own proves nothing about a boundary, because nothing about a 200 says whose record it was.
The role each request was made as, and the object each one reached. That is what turns a finding into something your engineer can reason about without asking us which account was which.
Written to be run against your own environment with your own credentials, so confirming the finding does not depend on anything we still hold.
Severity with its CVSS v4.0 vector, the CWE, and the OWASP API Security Top 10 category at the 2023 edition.
In the model with no auditor in it, findings pass a second automated gate before they are reported. It is a check on top of the exploit, not a substitute for it.
Where this sits
No vendor is named here — these are categories of work. Two of them see every request and neither can answer the question at the top of the list.
| Specification-driven scanner | Gateway policy and filtering | Scheduled API engagement | B-52 | |
|---|---|---|---|---|
| What it works from | The specification it was handed. | Live traffic, against rules. | The specification, and the hours bought. | What actually answers, plus a credential for each role. |
| Finds routes not in the specification | No. The specification is its world. | Sees them where they are used, and enforces nothing about whether they should exist. | Where the hours allow for looking. | Yes, in discovery, before the matrix is written. |
| Object level authorisation | Largely out of reach: every response is well formed. | No. It cannot know whose record that identifier refers to. | Yes, given credentials and time. | Worked as a class, with a credential per role and a matrix to test against. |
| What a finding costs you to confirm | Triage. A share of them are not real. | Not applicable; it blocks rather than reports. | Usually nothing; it was proved. | Nothing. Both exchanges arrive with it. |
| Cadence | Continuous. | Continuous. | When it is scheduled and staffed. | The interval you set, or the pipeline that built the release. |
| Whose signature it carries | None. | None. | The firm that ran it. | Security Brigade’s, in the two models with an empanelled auditor in them. |
What it works from
Finds routes not in the specification
Object level authorisation
What a finding costs you to confirm
Cadence
Whose signature it carries
On the gateway
A gateway doing authentication, rate limiting and schema validation is doing real work, and an interface without one is worse off for it. What it cannot do is decide whether the record this caller asked for is a record this caller owns, because that answer lives in your data rather than in the request. Every entry at the top of the API list is that shape of question, which is precisely why they survive a gateway — and why this class is built around asking them with two credentials instead of one.
Filing
Coverage is identical across the three delivery models. What differs is whose signature the report carries.
| Obligation | What it asks for, and which model produces it |
|---|---|
| SEBI CSCRF | Annexure L of the circular dated 20 August 2024 names APIs explicitly, alongside applications, infrastructure, operating systems, databases and cloud. Where the filing names an empanelled auditor, take the expert-verified or the human-led model. |
| Read 2026-09-08. | |
| PCI DSS v4.0.1, requirement 11.4.3 | Where the interface is internet-facing it sits inside the external perimeter that requirement asks to be penetration tested at least once every twelve months and after any significant infrastructure or application upgrade or change. |
| Requirement text read 2026-09-13. | |
| A periodic application security assessment | Any of the three delivery models covers the testing. Where the filing names an empanelled auditor, two of them produce output that can carry the signature. |
| Evidence of remediation | Each finding carries through open, fixed, retested and closed, and closes on a retest that cannot reproduce it — which on this class means the second request stops succeeding. |
SEBI CSCRF
Read 2026-09-08.
PCI DSS v4.0.1, requirement 11.4.3
Requirement text read 2026-09-13.
A periodic application security assessment
Evidence of remediation
On empanelment
CERT-In empanelment is held by Security Brigade, and under the framework it attaches to the testing rather than only to the firm invoicing for it. That is why the expert-verified and human-led models produce a report that can be filed under it and the fully autonomous model does not. Which routes were worked, and with how many roles, is the same in all three.
Worked example
Four steps. The first is a file nobody thought of as an exposure; the fourth is somebody else’s records.
| Link | Alone | In sequence |
|---|---|---|
| 1 A specification nobody meant to publish | A document listing operations. | It names internal operations, with no security definitions against any of them. |
| 2 An operation with no gate | A route that answers without a session. | It is one of the operations that document named. |
| 3 A service that signs what it is handed | A token endpoint. | The claim inside the token becomes whatever the caller chose to put there. |
| 4 Another account’s records | A well-formed response, status 200. | The identifier was changed, the server honoured it, and nothing about the exchange looked wrong. |
Measured
The benchmark was run in parallel rather than in sequence: B-52 and Security Brigade’s expert assessment team worked the same targets at the same time, and everything either of them produced went into one pooled set with each item counted once. B-52 reached 90–95% of that set, and part of what it reached was absent from the team’s own output — which is why the pooled set is larger than either side alone, and why the expert-verified model is a real option rather than a hedge.
One scan is one application or target, and the entry tier is $500. The credential set is the input that most changes what comes back, so it is worth settling before anything starts.