Section 1: API security foundations
Why APIs fail differently
Traditional web applications render pages on the server and show users only what the server chooses. APIs are different: they expose data and operations directly, and the client, often a single page app or a mobile app, decides what to display. Anything the API returns can be read by the user, and any endpoint the client calls can be called directly with any parameters.
That changes where security has to live. Every check must be in the API itself, because the client is fully under the user's control.
The OWASP API Security Top 10
OWASP publishes a separate Top 10 for APIs. The 2023 edition lists:
- Broken object level authorisation
- Broken authentication
- Broken object property level authorisation
- Unrestricted resource consumption
- Broken function level authorisation
- Unrestricted access to sensitive business flows
- Server side request forgery
- Security misconfiguration
- Improper inventory management
- Unsafe consumption of APIs
Notice how many entries are about authorisation: which objects, which properties and which functions a caller may access. That is the centre of API security, and the focus of this section.
Predictable identifiers make it worse
APIs commonly expose identifiers in paths: /projects/1042/tasks/88. Anyone can change the number. Using random UUIDs makes guessing harder, but it is not a defence: identifiers leak through logs, shared links and other responses. The defence is checking ownership on every request.
Our sample API
The course API manages organisations, projects, tasks and members, with roles of viewer, editor and admin within each organisation. It has a web client and a mobile client, uses OAuth 2.0 access tokens issued by an identity provider, and calls two external services. You will find it contains several deliberate mistakes; part of the fun is fixing them one by one, each with a test.
A note on scope
We focus on what you control as an API developer: code, configuration and tests. Gateways, web application firewalls and API security products are useful extra layers, and we discuss where they fit, but none of them can know your authorisation rules. Those must be in your code.