OWASP API Security Top 10: The Vulnerabilities Shipping in Production Right Now
The OWASP API Security Top 10 is updated periodically based on analysis of real API vulnerabilities in production systems. The list is not theoretical. The vulnerabilities it documents are the ones that security researchers find in bug bounty programs, that appear in breach disclosures, and that affect applications built by teams that considered security during development. Their persistence on the list across multiple editions reflects the difficulty of eliminating them in complex systems, not a lack of awareness that they exist.
The two vulnerabilities at the top of the list — Broken Object Level Authorization and Broken Authentication — account for a disproportionate share of actual API security incidents. Understanding why they persist is more useful than understanding what they are.
Broken Object Level Authorization
BOLA — also called Insecure Direct Object Reference — occurs when an API endpoint accepts an object identifier in the request and returns or modifies the object without verifying that the requesting user is authorized to access that object. A request to /api/orders/12345 returns the order with ID 12345 regardless of whether the authenticated user owns that order.
The implementation error is an authorization check that validates authentication — verifying that the request comes from a legitimate user — without validating that the authenticated user is permitted to access the specific object being requested. In a system with many users and many objects, the authorization check that is easy to implement is the coarse-grained one: is this user authenticated? The check that prevents BOLA is the fine-grained one: does this authenticated user own or have permission to access this specific object?
Fine-grained authorization at the object level must be implemented for every object-fetching operation in the API. The check cannot be centralized in a middleware layer that does not know which user owns which object. It must be applied at the data access layer, where the user’s identity can be joined against the object’s ownership information.
BOLA persists because it is not detectable by automated scanning without understanding the application’s intended access control model. A vulnerability scanner cannot determine whether the user requesting order 12345 should be able to access it without knowing the business rule that defines ownership. Manual security review and specific test cases that verify cross-user access control enforcement are the only reliable detection mechanisms.
Broken Authentication
Authentication vulnerabilities in APIs cover a range of failures: credential stuffing enabled by absent rate limiting on authentication endpoints, JWT validation that accepts tokens with modified algorithms, API keys transmitted in URLs where they appear in server logs and browser history, and password reset flows that can be exploited to take over arbitrary accounts.
The JWT-specific failures deserve particular attention because they are counterintuitive. JWT libraries that accept the alg: none header — disabling signature verification — allow attackers to forge arbitrary tokens without knowing the signing key. Libraries that allow algorithm substitution attacks — where the attacker changes the algorithm from RS256 to HS256 and signs with the server’s public key as the HMAC secret — produce tokens that are cryptographically valid by the wrong algorithm. These failures are not theoretical. They appear in bug bounty programs regularly.
The correct JWT implementation validates the algorithm explicitly rather than trusting the algorithm specified in the token header, rejects tokens signed with none, and validates all required claims — expiration, issuer, audience — on every token verification.
Excessive Data Exposure
APIs that return more data than the requesting client needs and rely on the client to filter irrelevant fields create a class of information disclosure vulnerabilities that OWASP calls Excessive Data Exposure. A mobile app endpoint that returns the full user object including internal fields, administrative flags, and other users’ data embedded in related objects trusts the mobile client to display only the appropriate subset. When the client is intercepted or replaced, all the returned data is accessible.
The fix is returning only the data that the requesting client is authorized to see, filtered at the server. Not filtered at the client. The server does not know how the client will use the data it returns, and the server cannot control what clients do with data once they receive it. Server-side filtering of response data based on the requesting user’s authorization scope is the only reliable mitigation.
Security vulnerabilities in APIs are not primarily a failure of security knowledge. They are a failure of security discipline applied consistently to every endpoint, every object access, and every authentication flow. The OWASP list documents where that discipline most commonly fails. The review against the list is the discipline.