Protecting an API

Authentication tells an API who is calling; it does not stop that caller reading someone else's data, setting fields they should not touch, sending a body large enough to stall the server, or making ten thousand requests a minute. Most API breaches are not broken cryptography. They are a missing check on an ordinary request, and most of those checks are decided when the API is designed.

The topic opens on the OWASP API Security Top 10 as a map, then works through five risks in the same order each time: what goes wrong, a request that shows it, the fix, and how to test for it. Object-level authorisation comes first, with an example of one changed order number. Mass assignment and data exposure follow, then input validation and rate limits a client can read. CORS closes the family, with a gotcha on what it does not protect, and an exercise finds five weaknesses in one endpoint.

It builds on authentication and the 401 and 403 codes from the topic on authenticating API clients.

By the end you can name the risks a design decides, spot a missing object-level check, prevent mass assignment, design a 429 a client can act on, configure CORS for a front end, and say what CORS does not protect.