The API Top 10 is mostly an authorisation list, and that decides what a tool can do
The web Top 10 is a list of things that can be done to an application. The API Top 10 is mostly a list of things an application fails to decide, and the difference is the whole problem. Its top entry has been broken object level authorisation since 2019, and no scanner finds that by recognising a pattern, because whether a record belongs to the caller is a fact about your data rather than a property of your code. Below is which entries this platform carries, how each result is established, and which of the ten nothing here touches.
Which layer settles which entry
Every entry named here is one the control pack really carries, and each is settled by a named layer rather than by the report in general. An entry no layer reached is uncovered, which is a different result from passing.
Runtime validation
E4The layer this list was waiting for. API1:2023 is an authorisation question, and an authorisation question is answered by asking for one account's object with another account's session, which is what this does. API3:2023 is answered by sending properties the endpoint did not ask for and seeing which ones it accepts. API4:2023 is answered by a bounded burst and by watching what an expensive operation costs to call. None of those are patterns, which is why nothing static settles them.
Repository validation
E2Reads the handlers, which is where an absent check is visible. A record fetched from a request identifier with no ownership resolution is the source half of API1:2023 and API5:2023, and it cites the file. What it cannot do is tell you the check was the right one: source shows a check exists, and only a request shows it refused the caller it should have.
Public URL scan
E4Needs only the address, and on this list it speaks to one entry. API8:2023 covers missing transport security, missing security headers and errors that describe the system, and all three are read off the responses the deployment actually returns. It reaches nothing about authorisation, which is where this list mostly lives, so most of the Top 10 is reported uncovered rather than assumed.
Every API Top 10 entry the pack carries
Seven of the thirteen controls carry an API Security entry, covering five of the ten. Each row gives the entry, how the result is established, and what passing requires. The five the pack does not reach are named below the table rather than left for you to notice.
What this list is, and what it is not
Most confusion about the API Top 10 comes from reading it as the web Top 10 with a different cover. It is a different document with a different centre of gravity.
Injection is not on it, and that is the clearest signal of what it is
The 2023 edition dropped injection as its own entry. Not because injection stopped existing, but because the risks that actually end APIs are authorisation and consumption rather than payload handling. Five of the ten entries are about who may do what. If a tool's API security coverage is mostly pattern matching, it is covering the half of the list this document deliberately moved away from.
BOLA has been number one since 2019 for a structural reason
Broken object level authorisation stays at the top because it cannot be found by looking at code in isolation. The endpoint is correct, the query is correct, the identifier is valid. What is wrong is that nobody checked whose identifier it was, and that is only visible if you know who the caller is and who owns the record. It is the clearest example on this list of a finding that needs two accounts rather than a scanner.
Function level and object level authorisation are different failures
API5:2023 is an admin endpoint that an ordinary user can call. API1:2023 is an ordinary endpoint returning somebody else's row. A product can get one right and the other wrong, commonly the first, because roles are visible in the interface and ownership is not. Both are in the pack and they are tested as separate questions.
Half the list needs a person and the pack says so
The five entries no control here carries are broken authentication, unrestricted access to sensitive business flows, server side request forgery, improper inventory management and unsafe consumption of APIs. Two of those are about your business logic and your API estate, which a tool cannot enumerate without being told what exists. They are reported uncovered rather than being quietly folded into a coverage number.
Coverage quoted without entry numbers is a claim you cannot check
A percentage tells you nothing, because you cannot see what was in the denominator. The only version that survives a reader is the specific one: these entries, established this way, everything else untouched. That is the shape of the table above and it is the shape to ask for from anyone else.
What the result looks like
An illustrative extract, not a real customer result. Every row carries the evidence grade behind it, and a control nobody could establish says so.
| Control | Status | Evidence | Note |
|---|---|---|---|
| Object ownership is enforced server-side | Failed | E4 | API1:2023, one account's object returned to another account's session |
| Authentication endpoints are rate limited | Verified | E4 | API4:2023, a bounded burst was throttled at the edge |
| Security response headers are present | Partial | E4 | API8:2023, no content security policy on the document response |
| Server-side input validation on state-changing endpoints | Verified | E4 | API3:2023, unexpected properties rejected rather than bound |
| Verified backups and restore procedure | Uncovered | Not graded | The pack maps no API Security entry to it, and the list does not cover recovery |
Mapped to published standards
Each control is tested against a named clause, so a result means something outside our own vocabulary. Mapping is not certification, and none of these bodies endorse StackAttest.
What this does not tell you
- It is not a penetration test. A deterministic check and a runtime probe are not an adversarial human engagement, and there are classes of weakness only a person hunting for them will find.
- It is not SOC 2 and does not replace it. SOC 2 attests to organisational controls over time; this validates technical controls in the software. They answer different questions for different buyers.
- It does not replace human due diligence. It gives a reviewer repeatable evidence to start from, which is a different thing from being the reviewer.
- Controls the run could not reach are reported as uncovered rather than passed. A result you did not earn is worse than no result.
- It is not a certification and there is no such thing to award. OWASP publishes this list openly and neither OWASP nor the API Security project endorses, accredits, reviews or has any relationship with StackAttest.
- It does not cover the list. Five of the ten entries have no control behind them here, including broken authentication and unrestricted access to sensitive business flows. Those are untouched rather than passed.
- It cannot enumerate your API estate. Improper inventory management is a question about which versions and environments are exposed, and a tool that has been handed one address has been handed one address.
- A passing entry is about the endpoints that were reached. An authorisation test proves what it tested, and an endpoint nobody exercised is not covered by a result about the ones that were.
Questions
Why is injection missing from the API Security Top 10?
The 2023 edition folded it away because it was not what was actually ending APIs. The entries that replaced it are about authorisation and resource consumption, which is a considered statement about where API risk really sits rather than a claim that injection is solved. If you want the injection view, the web Top 10 and CWE-89 are the right references.
Can a scanner find broken object level authorisation?
Not by pattern. It can find the shape that usually precedes it, which is a handler taking an identifier from the request, and that is a lead rather than a finding. Establishing BOLA needs two accounts and a request made with the wrong one, because the question is whose record it is and that is not written anywhere in the code.
What is the difference between API1 and API5?
API1:2023 is object level: an endpoint anybody may call returns a row that belongs to somebody else. API5:2023 is function level: an endpoint only some roles should be able to call at all is callable by anyone. Products commonly handle the second and miss the first, because roles show up in the interface and ownership does not.
Our API is internal. Does this list still apply?
The authorisation entries do, and arguably more than for a public API, because internal services often trust their callers by convention. The entries about public exposure and inventory matter less. Which parts apply is a judgement about your architecture, and it is one of the things nothing automated should make for you.
Related
Find out what is actually true of your application
Start with the layer you can run today. The report says which layers ran and what they could not reach, so the result is honest about its own limits.