Card 01/ 10
The OWASP API Security Top 10
Ten risks recur across real API breaches, and five of them are decided when the API is designed.
The OWASP API Security Top 10 is a list, last revised in 2023, of the risks behind most real API breaches, published by the Open Worldwide Application Security Project. Five of them are decided by how an API is designed, and this topic covers those five. Each card on a risk answers the same four questions in the same order: what goes wrong, a request that shows it, the fix, and how to test for it.
| Risk | What goes wrong | A request that shows it | The fix | How to test |
|---|---|---|---|---|
| Broken object level authorisation, API1 | A caller reads or changes another user's object | GET /orders/1002 by the owner of 1001 | Check ownership on every object | Two accounts, swap ids |
| Broken object property level authorisation, API3 | A caller sets or sees fields they should not | PATCH /users/me with role admin | Allow-list fields in and out | Send and look for extra fields |
| Unvalidated input, part of several entries | Malformed or huge values reach the code | A 50 MB name, a negative quantity | Validate against a schema at the edge | Boundary and oversized values |
| Unrestricted resource consumption, API4 | One client exhausts the API | Ten thousand requests a minute, limit=1000000 | Rate limits, size and page limits | A load test past the limit |
| Security misconfiguration, API8, here CORS | Any website can read responses in a browser | A reflected Origin with credentials | An allow-list of origins | Requests with an unlisted Origin |
The other five. Broken authentication (API2), unrestricted access to sensitive business flows (API6), server-side request forgery (API7), improper inventory management (API9) and unsafe consumption of other APIs (API10). Authentication has its own topic in this subject; the rest are operational as much as design, and are worth reading on the OWASP site.
Why these five are design decisions. Each is settled by a rule the endpoint follows on every request: whose object this is, which fields may change, what a valid value looks like, how much one client may ask for, and which websites may read the answer. Writing those rules into the contract is cheaper than finding them in a penetration test.
Authorisation leads the list. Two of the five are authorisation failures, and API1 has led the list since its first edition. Being signed in is where checking begins, not where it ends.
So review every endpoint against the same five questions, and write each answer into its contract.
← → move through sections and cards