Dit artikel is alleen in het Engels beschikbaar.
APIs fail differently from web pages. A web application has forms and rendered pages; an API exposes objects and actions directly, often to many clients at once. The most common serious findings are not the classic injection flaws but failures of authorisation on individual objects. This post covers what an API test actually looks for, following the OWASP API Security Top 10.
Broken object level authorisation
Broken object level authorisation, or BOLA, is the single most common serious API finding. The API authenticates the caller but does not check that the caller owns the specific object requested.
GET /api/v1/orders/1043 HTTP/1.1
Authorization: Bearer <valid token for user A>
If changing 1043 to 1044 returns another user’s order, the object is not scoped to its owner. The fix is to check ownership on the server for every object access, based on the authenticated identity, and never to rely on the client only requesting its own identifiers.
In an API test, the first question is rarely “can I inject” and almost always “can I reach an object that is not mine”.
Broken authentication and tokens
APIs lean on tokens, and tokens fail in specific ways: they do not expire, they are accepted after logout, the signature is not verified, or the same token works far beyond its intended scope.
The fix is short-lived tokens, server-side validation of every token including its signature and scope, and revocation that actually takes effect. Authentication that is only tested at the front door is not tested.
Excessive data exposure and mass assignment
Two related problems come from trusting the object shape. Excessive data exposure is when an endpoint returns more fields than the client needs, such as internal flags or another user’s details, and relies on the client to hide them. Mass assignment is the reverse: the client sends extra fields, such as "role": "admin", and the server binds them without checking.
The fix for both is an explicit contract: return only the fields a response needs, and accept only the fields an action is allowed to change. Never bind a request body straight onto a stored object.
Resource consumption and rate limits
An API without limits can be abused for volume: credential stuffing against a login, scraping through an enumerable endpoint, or expensive queries that exhaust the backend. These are not always exploitable in the classic sense, but they are real risk.
The fix is rate limiting and quotas per client and per endpoint, with the tightest limits on authentication and on any endpoint that is expensive to serve.
The API Top 10 at a glance
| Risk | The short version of what to check |
|---|---|
| Broken object level authorisation | Can a caller reach an object that is not theirs |
| Broken authentication | Do tokens expire, validate, and revoke correctly |
| Broken object property authorisation | Can a client read or set fields it should not |
| Unrestricted resource consumption | Are there rate limits and quotas |
| Broken function level authorisation | Can a normal user call an admin action |
| Server-side request forgery | Can a supplied URL be pointed at internal services |
| Security misconfiguration | Defaults, verbose errors, permissive CORS |
Closing
An API test is mostly about authorisation: object by object, function by function, token by token. The injection flaws still matter, but the findings that cause real damage are the ones where an authenticated caller reaches something that was never meant for them. Every finding should arrive with the request that proves it and a clear fix.
For how an API assessment is structured, see the web and API penetration testing service page.
