API security: the OWASP API Top 10 in practice

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.

Inventory and contract first

Maintain an API catalogue with owner, environment, version, base URL, data class, consumers and retirement date. OpenAPI helps, but compare specifications with gateway traffic and logs to find shadow and zombie APIs. An endpoint removed from documentation may still respond.

Contracts should constrain input and output fields. Reject unknown properties where appropriate, allowlist mutable fields and avoid serialising complete domain objects into responses.

Object, property and function authorisation

The 2023 OWASP API Top 10 distinguishes three levels. BOLA concerns a specific object, Broken Object Property Level Authorization concerns its fields, and Broken Function Level Authorization concerns a whole function. A router role check is insufficient when the user controls a resource identifier.

Build matrix tests across role, owner, tenant, object state and operation. Run them after every authorisation change. Random identifiers reduce guessing but never replace a server-side access decision.

Resource consumption and business logic

Per-IP rate limiting does not cover every case. Limits should include identity, tenant, operation, query cost and downstream resource. Control complexity, response size and time for exports, search and GraphQL.

Sensitive Business Flows need business rules around account creation, reservations, vouchers or resets. A bot can abuse valid requests without a classic technical vulnerability.

Consuming external APIs safely

Treat integration responses as untrusted input. Validate schema, timeout, redirects, size and content type. Never pass external error text directly to a client or as commands to an internal system. Use separate credentials and constrained egress.

Combine these controls with OAuth security and contract testing in CI.

Sources: OWASP API Security Top 10 2023, OWASP API Security 2023 release notes.