Modern applications run on APIs. The user-facing web application is increasingly a thin layer over a substantial API estate; mobile applications consume APIs directly; service-to-service communication runs on internal APIs; partner integrations expose APIs to external consumers. The data flow concentrates in APIs, the attack surface concentrates in APIs, and yet most application security programmes treat API-specific security as a footnote to web application security. The OWASP API Security Top 10 exists because API failure modes are different enough from web application failure modes that the general OWASP Top 10 does not cover them adequately.
Broken Object Level Authorization: The Vulnerability That Dominates
API1 — Broken Object Level Authorization (BOLA) — is the most prevalent and consequential API vulnerability. It occurs when an API endpoint accepts an identifier for an object and returns the object without verifying that the requesting user is authorised to access that specific object. The endpoint authenticates the user, the endpoint validates that the user has access to the endpoint, but the endpoint does not check that the specific object identifier belongs to the user requesting it. The attack is trivial — change the identifier in the URL — and the consequence is direct unauthorised access to other users' data.
Why BOLA Is So Common
Endpoint-level authorisation is the framework default — most web frameworks make checking "can the user access this endpoint" easy. Object-level authorisation is custom code per object type — there is no framework-level mechanism that knows whether user A can access invoice 12345. The framework default is sufficient for web application contexts where the framework also renders the object and includes the authorisation check in the rendering layer. APIs have no rendering layer, so the authorisation check has to be explicit in the API code. The check is often missed, even by experienced developers, because the framework does not produce a visible error when the check is omitted.
Broken Authentication and Excessive Data Exposure
API2 — Broken Authentication — covers the same vulnerability class familiar from web applications but with API-specific manifestations. Long-lived API keys without rotation. Token validation that does not check expiration. JWT signature verification that accepts unsigned tokens. API3 — Excessive Data Exposure — addresses APIs that return more data than the client needs, expecting the client to filter. Mobile and web clients filter the display; sensitive data still travels over the wire and may be logged or intercepted. Returning only what the consumer needs is API hygiene that most APIs implement poorly.
A pattern in API security findings: an internal API was built with the assumption that it would only ever be consumed by trusted services within the network. The API was promoted to production exposure without revisiting the authorisation model, the BOLA vulnerabilities that did not matter when consumers were trusted now expose customer data, and the team discovers the gap during a penetration test or worse. API security has to be designed for external consumption from the start, even when current consumers are internal — because the consumer model changes faster than the security model gets revisited.
Lack of Resources & Rate Limiting
API4 — Lack of Resources & Rate Limiting — covers APIs that do not constrain the resources a single consumer can use. The vulnerability enables denial-of-service attacks, cost amplification attacks (against APIs with per-call billing), and brute-force attacks against authentication endpoints. The defence is rate limiting calibrated to legitimate usage patterns, with separate limits for unauthenticated and authenticated endpoints, and per-account limits that prevent a single compromised credential from consuming disproportionate resources.
Mass Assignment and Security Misconfiguration
API6 — Mass Assignment — occurs when APIs accept entire objects and update all fields without restricting which fields the client should be able to modify. Clients can update fields they should not be allowed to update — role assignments, billing state, account ownership — by including them in API requests. API7 — Security Misconfiguration — covers the long list of configuration weaknesses that affect APIs specifically: verbose error messages exposing internal structure, missing security headers, default API keys, misconfigured CORS that effectively disables origin restrictions. None of these are exotic; all of them are common in API estates that were not designed with security in mind.
Defensive Practices That Hold Up
- Object-level authorisation enforced on every endpoint that returns or modifies object data
- Authentication tokens with appropriate expiration, rotation, and signature validation
- Output filtering that returns only what the consumer needs, not the full object
- Rate limiting calibrated to legitimate use patterns, per-account where relevant
- Explicit allow-lists for mass-assignable fields rather than accepting whole objects
- API security testing integrated into the development workflow, not as a periodic external exercise
- Inventory of APIs across the estate, with deliberate retirement of unused endpoints
Why API Security Deserves Its Own Programme
For organisations whose business model depends on APIs — most modern technology businesses, increasingly most digital-first businesses generally — API security is the application security discipline that matters most. The OWASP API Security Top 10 provides the structured starting point, but the discipline goes beyond the list. API-specific threat modelling, API gateway design, API testing integrated into delivery, and API inventory management are all components of a programme that treats APIs as the primary surface they have become. Organisations that have made this shift produce different security outcomes than organisations still treating APIs as a footnote in their web application security programme.