API security: the OWASP API Top 10 in practice
APIs are now the most common target for application attacks. We cover the key OWASP API Top 10 flaws — led by BOLA — and how to avoid them.
Web and mobile apps now communicate mainly through APIs. That has shifted the centre of gravity of attacks: less and less often is “the page” broken, and more and more often the interface that feeds it. OWASP maintains a separate API Security Top 10, because APIs have their own specific class of flaws. Here are the ones we run into most in testing.
BOLA — the most dangerous and most common
At the top of the list sits Broken Object Level Authorization (BOLA), also known as IDOR. The point is that the API authenticates the user correctly but doesn’t check whether a given object belongs to them. The classic example: a request GET /api/invoices/1043 returns an invoice, and changing the number to 1044 returns someone else’s — because the backend trusts the identifier in the request.
The defence: authorisation at the level of every object, server-side, for every request. Never assume that because a user is logged in, they’re entitled to the resource with the given ID.
Broken authentication and excessive data
- Broken authentication — weak token mechanisms, no attempt limits, poorly validated JWTs. APIs are often a “back door” bypassing the controls present in the web interface.
- Excessive data exposure — the endpoint returns the whole object while the front end shows only part of it. An attacker reads the raw response and gets fields they shouldn’t see (passwords, roles, internal data). Filter data server-side, not in the client.
Missing limits and broken function-level auth
- No rate limiting (Unrestricted Resource Consumption) — an API without request limits enables enumeration, brute force and costly abuse. Limit the rate and size of requests.
- Broken Function Level Authorization — a regular user calls an admin endpoint because function authorisation is inconsistent. Enforce permissions centrally and deny by default.
How to approach API security
- Authorisation on every request and every object — that’s the foundation, not an add-on.
- A full inventory of endpoints, including old versions and “shadow APIs” — you can’t protect what you don’t know about.
- Input validation and strict response schemas (return only what’s needed).
- Logging and anomaly monitoring — unusual ID enumeration is a sign of an attack.
APIs are often the shortest path to the data — which is why we test them as thoroughly as the rest of the application. It’s also where the threads from vulnerability prioritisation meet: context and exposure matter. If you’d like to test your API’s security, book a test.
Sources and further reading: OWASP API Security Top 10.