Bridge WAF
OWASP API Security Top 10: what limits and filters can reach
The OWASP API Security Top 10 is the OWASP list of risks specific to APIs, and the current edition is 2023. Three of its ten items are authorisation flaws, which only the API itself can check. Rate limits and a request filter reach the items that show up as volume, as automation, or as a recognisable request.
Quick facts
- Published by
- The OWASP API Security Project
- Current edition
- 2023, checked on 8 October 2026
- Items
- Ten, numbered API1:2023 to API10:2023
- Authorisation items
- API1, API3 and API5: whether this caller may reach this object, field or function
- Where limits and a WAF help
- API4 resource consumption and API6 business flows through rate; parts of API2 and API7 through the request
The list is separate from the main OWASP Top 10 and changes on its own schedule. How to test an API against it is on API security testing.
The ten items, and what reaches them
An API request usually looks valid; the wider practice around it is on API security. The question each item asks is whether the request carries anything a filter or a counter could see.
| Item | What goes wrong | What limits and a filter can do |
|---|---|---|
| API1:2023 Broken Object Level Authorization | A caller reads or changes an object that is not theirs by changing its identifier | Nothing. Only the API knows who owns the object |
| API2:2023 Broken Authentication | Weak sign-in, token or credential handling | Part. Repeated sign-in attempts can be rate limited; token handling cannot |
| API3:2023 Broken Object Property Level Authorization | A caller reads or writes fields of an object it should not, including mass assignment of fields the client was never meant to set | Nothing. The rule about which field belongs to whom lives in the API |
| API4:2023 Unrestricted Resource Consumption | Requests that cost more than anyone budgeted: size, count, frequency | Most. Rate limits bound how much a caller can consume |
| API5:2023 Broken Function Level Authorization | A caller reaches an administrative or privileged function | Nothing. Who may call which function is decided in the API |
| API6:2023 Unrestricted Access to Sensitive Business Flows | A legitimate flow, such as buying or booking, run by automation at a scale that hurts the business | Part. Limits slow automation down; deciding which flows are sensitive is yours |
| API7:2023 Server Side Request Forgery | The API fetches a URL supplied by the caller and reaches somewhere it should not | Part. Recognisable payloads can be matched; restricting where the API may connect is yours |
| API8:2023 Security Misconfiguration | Insecure defaults, missing hardening, verbose errors | Little |
| API9:2023 Improper Inventory Management | Old, undocumented or forgotten API versions still running | Nothing. A filter protects only what is placed behind it |
| API10:2023 Unsafe Consumption of APIs | Trusting data from third-party APIs without checking it | Nothing. It happens in your outbound calls |
Item names are from the OWASP API Security Top 10 2023; the right-hand column is this page's reading of what rate limits and a request filter can observe.
Why so much of it is authorisation
An API hands out data by identifier: an order number, an account, a document. The request asking for someone else's order looks exactly like the request asking for your own, with a different number in it. That is broken object level authorization, the same flaw as IDOR in web applications.
That is why object, field and function access sit at API1, API3 and API5, and why no filter in front of the API can stop them. The check has to happen where the API knows who the caller is and who owns the object, on every request.
Where volume is the attack
API4 and API6 are about quantity. Nothing in a single request is wrong; the harm is in how many there are, how large, or how fast.
This is the part rate limiting reaches. Which subject a limit counts, an address, an account or a key, decides who shares a budget, and choosing the subject covers the trade. API abuse describes the same traffic from the side of the attack.
How it relates to the main Top 10
The two lists overlap in places. Server-side request forgery is API7 here and part of A01 in the OWASP Top 10:2025; misconfiguration appears in both.
They are still separate lists for a reason. An API is consumed by software, so its failures cluster around authorisation and consumption rather than around what a browser renders.
Questions
What is the OWASP API Security Top 10?
The OWASP API Security Top 10 is the OWASP list of the ten most important risks specific to APIs. The current edition is 2023.
Can a WAF stop broken object level authorization?
No. A request for someone else's object looks the same as a request for your own, so only the API, which knows who owns the object, can refuse it.
Is the API list part of the OWASP Top 10?
No. It is a separate OWASP project with its own edition. The lists overlap on request forgery and misconfiguration.
Which API risks do rate limits address?
Mainly API4 Unrestricted Resource Consumption and API6 Unrestricted Access to Sensitive Business Flows, and the sign-in side of API2. Limits bound volume; they do not decide who may access what.