OWASP API Security Top 10
In API security, the OWASP API Security Top 10 is a separate awareness list covering the weaknesses that appear specifically in application programming interfaces. It exists because APIs fail differently from web pages: the object graph is exposed directly, and most of the entries are authorisation problems rather than injection problems.
How it works
The list is maintained by the same foundation as the general web list and is deliberately narrower. Its opening entries deal with authorisation at the level of individual objects and at the level of functions, and it goes on to cover authentication weaknesses, unrestricted consumption of resources, mass assignment of properties, security misconfiguration, poor inventory of API versions and hosts, and unsafe consumption of third-party APIs.
Reading the two lists side by side shows the difference in emphasis. The web list is dominated by what an attacker can inject. The API list is dominated by what an attacker is allowed to ask for, which is exactly the shift you would expect when the server stops rendering pages and starts answering direct questions about objects.
What goes wrong
The most common misuse is running a web scanner over an API and reporting against this list. A scanner without the specification does not know the object identifiers, cannot construct a second tenant, and therefore cannot detect broken object level authorisation, which is the first entry and the one that leaks the data. What it can find is misconfiguration and missing headers, so the report looks complete and covers none of the categories that matter.
The second is inventory. The list includes improper inventory management for a reason we see on nearly every engagement: the previous version of the API is still deployed, undocumented, and enforces the checks that were added in the current one only partially. A shadow API is not an abstract governance issue, it is the endpoint we use.
Third, mass assignment is consistently under-tested because it needs someone to try sending fields the documentation does not mention, such as a role or a tenant identifier, and see whether the model binds them.
Where this shows up in an audit
We take the specification, generate the request set from it, and then test outside it, because the entries about inventory and consumption only appear when you leave the documented surface. Findings are mapped to the list so a client can compare years, and anything with no category is reported on its own terms. Confirm the current edition before citing entry numbers, since they are renumbered between releases. This is part of how an API assessment is structured.