The OWASP API Security Top 10, In Practice

The OWASP API Security Top 10 exists because API risk did not map cleanly onto the original web application list. It is a good document, currently in its 2023 edition, and it is worth reading as OWASP wrote it. What follows is the practitioner overlay: what each risk actually looks like when you test for it, and which ones a tool will ever find.

One note before the list. This is the API Top 10, which is a separate project from the general OWASP Top 10 for web applications. They get conflated in procurement documents constantly, and they are different lists with different editions.

The four that need a human

API1, Broken Object Level Authorization. You request an object that is not yours and the server returns it. The most common serious API finding by a wide margin, and untestable with a single account, which is why we insist on two tenants before an engagement starts. Covered in depth in broken access control.

API3, Broken Object Property Level Authorization. The endpoint is yours to call but the fields are not all yours to read or write. This is mass assignment and excessive data exposure merged into one risk in the 2023 edition, which was the right call because they are the same failure viewed from either direction. Found by sending fields that are not in the documentation and by reading what comes back rather than what the UI displays.

API5, Broken Function Level Authorization. A standard user calls an administrative endpoint directly and it works, because the only thing stopping them was that the interface did not render the button. Needs two privilege levels to detect.

API6, Unrestricted Access to Sensitive Business Flows. The most interesting entry on the list and the one most reports omit entirely, because it is not a bug. The endpoint works exactly as designed. The problem is that the design permits abuse at scale: buying the entire ticket inventory, creating accounts faster than any human would, scraping a whole catalogue through a legitimate search endpoint. Finding it requires understanding what the business would not want, which no scanner can represent.

Those four are all authorization or business-logic failures, and they are the four hardest to automate. That correlation is the practical lesson of the whole list.

The rest, briefly

API2, Broken Authentication. Token validation, algorithm confusion, expiry that is advisory rather than enforced, refresh handling, session invalidation on password change. Partly automatable, and worth attempting forgery deliberately so you can report the controls that correctly held.

API4, Unrestricted Resource Consumption. Missing rate limits and unbounded queries. Largely automatable, and in GraphQL it is sharper because query depth and batching give an attacker leverage a REST endpoint does not.

API7, Server Side Request Forgery. Less frequent than the authorization classes and disproportionately severe when present, because cloud metadata endpoints turn an SSRF into credentials.

API8, Security Misconfiguration. Verbose errors, permissive CORS, missing headers, debug endpoints. Mostly tooling work, and legitimately so.

API9, Improper Inventory Management. The one that gets ignored and should not. Deprecated versions still routing traffic, undocumented endpoints, an internal API reachable from outside. Old versions are frequently the weakest surface, because the authorization improvements only ever landed in the current one. This is discovery work rather than exploitation work.

API10, Unsafe Consumption of APIs. Trusting third-party API responses more than user input. Rising quickly as products integrate more services, and newly relevant where an AI agent consumes an external API and treats the response as instruction, which is the concern in prompt injection.

How to use the list, and how not to

Use it to communicate risk to people who do not read HTTP, to map findings so developers and auditors have a shared reference, and to check a vendor's report for obvious gaps. If a report contains no authorization findings at all, ask how many accounts the tester had.

Do not use it as a test plan. A methodology built to walk ten categories will systematically miss the business logic specific to your product, which is where API6 lives and where the findings that map directly to revenue tend to be. Coverage of the Top 10 is a floor, not a scope.

Also resist treating the ordering as a priority list for your remediation. The list is ordered by prevalence and impact across the industry; your queue should be ordered by what is exploitable in your environment, which is the argument in how to build a vulnerability management program.

Where BD Emerson fits

Our API penetration testing maps every finding to this list plus ASVS and CWE, and works multi-tenant and multi-privilege from the start so the four human-only categories are actually covered. Because APIs change faster than anything else you own, we test on specification change rather than annually as part of continuous penetration testing, and the same methodology extends to web application testing where the two surfaces meet.