Card 10/ 10
Recap: Protecting an API
Check the object, accept only known fields, validate every value, publish your limits, and do not lean on CORS.
Five design rules close the risks behind most API breaches.
- The OWASP API Security Top 10 maps the risks; five are settled by design.
- Object-level authorisation: scope every lookup to the caller, answer 404, test with two accounts.
- Mass assignment and exposure: name the fields each operation accepts and returns.
- Input validation: check every value against the contract at the edge, and limit everything that grows.
- Rate limits: 429 with
Retry-After, and headers that show the limit and what is left. - CORS: an allow-list of origins, never a reflected one with credentials.
- CORS is not access control: only browsers enforce it.
| Risk | What goes wrong | The fix | How to test |
|---|---|---|---|
| Object level authorisation | Another user's object by id | Scope lookups to the caller | Two accounts, swapped ids |
| Mass assignment and exposure | Fields set or seen that should not be | Allow-lists in and out | Extra fields sent and sought |
| Input validation | Bad or huge values reach the code | Schema checks and size limits | Boundary and oversized values |
| Resource consumption | One client exhausts the API | Rate, size and page limits | Load past the limit |
| CORS | Any site reads responses | An origin allow-list | Unlisted and null origins |
← → move through sections and cards