API Security: The OWASP API Top 10 in the Real World

The OWASP API Security Top 10 exists because API vulnerabilities behave differently from the classic web application flaws most tools were built to catch. A modern API exposes hundreds of granular endpoints, each accepting structured objects and each making its own authorization decision. When those decisions are inconsistent — and they usually are — an attacker with a valid account can reach data that was never meant for them. This piece walks the request lifecycle and maps the highest-impact risks to the exact point where they should be caught.

API1 — Broken Object Level Authorization (BOLA)

BOLA is consistently the number-one API risk, and for good reason: it is easy to introduce and invisible to most scanners. It occurs when an endpoint uses an identifier supplied by the caller — /orders/1043 — to fetch a record, but never checks that the record actually belongs to the authenticated user. Change the number, get someone else's order. The request is perfectly authenticated and perfectly malicious.

Getting it right

Object-level authorization must be enforced in the service, on every object access, by comparing the resource's owner against the caller's identity from the token — not from any value the client can influence. Prefer unpredictable identifiers (UUIDs) as defence in depth, but never rely on them as the control. Centralise the ownership check so it cannot be forgotten on the next endpoint someone adds.

API2 — Broken Authentication

Authentication flaws at the API layer include accepting unsigned or weakly signed tokens, failing to validate token expiry and audience, allowing credential stuffing against login endpoints, and leaking long-lived API keys in mobile apps or repositories. Because APIs are machine-to-machine, a single leaked key can be replayed indefinitely. Validate tokens rigorously at the gateway, rotate secrets, and treat authentication endpoints as high-value targets deserving their own monitoring.

API3 — Broken Object Property Level Authorization

Formerly split into "excessive data exposure" and "mass assignment," this risk is about returning or accepting the wrong fields. On the response side, APIs often serialise a full database object and rely on the client to display only some of it — so password_hash or is_admin travels over the wire to anyone who reads the raw response. On the request side, binding incoming JSON directly to a model lets a caller set fields they should never control. The fix is explicit, allow-listed schemas for both directions — never serialise or bind whole objects.

The recurring theme across the API Top 10 is trust misplaced in the client. Every value the client sends is attacker-controlled, and every field you return is something the attacker can read.

API4 — Unrestricted Resource Consumption

Without rate limiting and resource quotas, a single caller can exhaust CPU, memory, or third-party billing — an availability and cost problem as much as a security one. APIs that trigger expensive operations (SMS sending, file processing, large result sets) are especially exposed. Enforce per-client rate limits and request-size caps at the gateway, and apply stricter limits to sensitive operations like authentication and password reset to blunt brute-force attempts.

API5 — Broken Function Level Authorization

Where BOLA is about which records a user can reach, function-level authorization is about which operations they can invoke. Administrative endpoints frequently rely on being unlisted rather than being protected, so a regular user who guesses /admin/users or swaps a GET for a DELETE gets in. Deny by default, and derive an endpoint's required role from a policy, not from whether the UI happens to show a button.

Building it into the pipeline

The controls above only hold if they are verified continuously. Maintain an accurate API inventory — undocumented "shadow" and deprecated "zombie" endpoints are where breaches hide. Generate tests directly from your OpenAPI specification, add authorization test cases that attempt cross-tenant access with a second valid account, and run these checks in CI so a regression fails the build rather than the customer. Security testing that mirrors the request lifecycle above catches the flaws that generic scanners miss.