OWASP API Security Top 10: which two a bot layer actually fixes

Most people mean the web application list when they say "OWASP Top 10", but the API Security Top 10 is a separate document, and it exists because APIs fail differently. A web app is attacked through its rendering: injection, cross-site scripting, a template that trusts input. An API has no rendering layer, just a very large number of object identifiers and a very large number of ways to get the authorization check on them wrong.

The current edition is 2023, which replaced the 2019 list, and as of October 2026 there is no newer one, whatever a vendor slide deck implies.

The ten

Three of the ten are authorization failures, each at a different level of detail, which tells you most of what you need to know about where API security goes wrong. API1 is per-object: can this caller read that record. API3 is per-property: the caller may read the record, but should they see the isAdmin field or the internal cost price. API5 is per-function: the endpoint exists and the caller is signed in, but should a standard user be able to call DELETE /users/{id} at all.

The honest split

We sell a bot-protection and API-protection product, so there is an obvious temptation to claim this list as a feature matrix, but it is not one. Here is where an external traffic layer can help, and where it cannot.

Eight of the ten you fix in your own code. API1, API2, API3, API5, API7, API8, API9 and API10 are defects in handlers, configuration and process. If GET /orders/1004 returns another customer's order, your handler is missing an ownership check, and no amount of request scoring will supply it, because the layer in front of your API does not know which records belong to which customer. A WAF can sometimes hide the symptom of API7 or API8 by blocking an obviously malicious payload, but nothing external fixes a broken authorization decision.

API9, Improper Inventory Management, is worth singling out, because it is the one people skip and it is almost always true. It covers the staging host still answering on the internet, the /v1 you deprecated two years ago and never turned off, the undocumented endpoint a mobile client uses. You cannot defend what you have not listed, and most teams find their real API surface during an incident.

Two of the ten are automation problems. These are the ones where a traffic layer is the right tool, not a consolation prize.

API4:2023 — Unrestricted Resource Consumption

An endpoint that is cheap for the caller and expensive for you. A search that scans. An export that renders. A password reset that sends an email. A signup that provisions a record. An AI endpoint that bills you per token. There is no vulnerability in the usual sense, because every request is legitimate; the problem is the rate and the volume.

Simple per-IP rate limiting has not worked for years, because the traffic does not come from one IP. We see the same pattern all the time: a request flood spread across tens of thousands of residential addresses, each sending a handful of requests that sits well under any per-IP threshold individually but is enormous in aggregate. Defending API4 means identifying the client rather than the address. Is the thing making the request a browser with a person sitting in front of it? Are many apparently unrelated sessions in fact one actor behind a residential proxy pool?

API6:2023 — Unrestricted Access to Sensitive Business Flows

This is the most interesting item on the list, and the hardest to describe as a bug, because nothing is broken: the flow works exactly as designed, and is simply being run by software at a speed and frequency the business never intended.

Buy every ticket the moment they go on sale. Claim every promotional code. Book every appointment slot. Register ten thousand free accounts to use up the trial allowance. Scrape the whole catalogue every hour to undercut the pricing.

There is no authorization check to tighten, because the caller is genuinely allowed to buy a ticket. There is no payload to filter, because the request is well-formed and identical to a real customer's. OWASP's own guidance on API6 says plainly that the fix is to detect automation — device fingerprinting, client-side behavioural analysis, and spotting non-human traffic patterns — rather than to patch anything.

This item connects the API Top 10 to the rest of the abuse world. Nearly every entry in OWASP's Automated Threats taxonomy — OAT-005 scalping, OAT-001 carding, OAT-008 credential stuffing, OAT-011 scraping — is a specific way of exploiting a sensitive business flow. If you are writing an RFP, API6 is the requirement and the OAT codes are how you make it testable.

How to use the list

Run the authorization items as a code review, endpoint by endpoint, with the object identifier as the unit of work. Automated scanners find API8, and sometimes API7, but they are poor at API1 and API3, because knowing whether a response is wrong means knowing who owns the data.

Run API9 as an inventory exercise before anything else, because the rest of the list only covers endpoints you know about.

Run API4 and API6 as traffic problems. The question is not "is this request malformed" but "is this caller a person, and is this volume what we intended", which is a different kind of measurement and belongs in front of the application. It is what Prosopo Protect is for: scoring request intent across the human / agent / bot boundary, and naming the signal that fired when something is stopped, so the verdict can be argued with.

One last point on scoping, because it comes up in every procurement conversation we have. A vendor who claims to "cover the OWASP API Security Top 10" is claiming to fix your authorization logic, and cannot. Ask which specific items they address. If the answer is anything other than API4 and API6, with a WAF-shaped contribution to API7 and API8, you are being sold a slide rather than a control.