The OWASP API Top 10 is a standalone ranked list of the most common vulnerability classes specific to APIs, maintained separately from the general OWASP Top 10 because APIs expose a different attack surface than traditional web pages — no browser rendering, no DOM, but plenty of authorization logic that goes wrong in predictable ways. The most recent version (2023) reordered several categories from the 2019 list based on updated incident data, and broken authorization issues still dominate the top of the ranking.
Why does the owasp top 10 api list exist separately from the web Top 10?
Traditional web vulnerabilities like XSS assume a browser is rendering HTML; APIs typically return JSON or XML to a programmatic client, so browser-side risks like cross-site scripting matter less while authorization and data-exposure risks matter more. An API endpoint that returns a full user object when only a display name was needed doesn't look wrong to a browser-based scanner the way an unescaped script tag would — you need API-aware tooling that understands request/response schemas and authorization boundaries to catch it.
What is Broken Object Level Authorization (API1)?
BOLA happens when an API checks that a request is authenticated but never checks whether the authenticated user is actually allowed to access the specific object requested — so changing /api/orders/1001 to /api/orders/1002 in the URL returns someone else's order because the object ID is trusted, not the requester's ownership of it. It's ranked first because it's both the most common finding in real API audits and one of the simplest to exploit; no special tooling is required, just changing an ID and observing the response.
What is Broken Authentication (API2)?
This covers weak or missing authentication controls specific to APIs — credential stuffing against login endpoints with no rate limiting, JWTs signed with weak or hardcoded secrets, or API keys that never expire and get committed to public repositories. Because APIs are often consumed by other services rather than humans clicking through a login form, weak authentication here can be exploited entirely by automated tooling at scale.
What is Broken Object Property Level Authorization (API3)?
A newer category (merging older "excessive data exposure" and "mass assignment" entries) covering endpoints that expose or accept more object properties than they should — returning a user's hashed password field in a profile response, or accepting a role field in a signup request payload that lets a client silently self-promote to admin. This is a common finding in APIs built by binding request bodies directly to database models without an explicit allowlist of writable fields.
What is Unrestricted Resource Consumption (API4)?
APIs without rate limiting, payload size limits, or pagination caps are vulnerable to both intentional denial-of-service and accidental resource exhaustion — a single client requesting an unbounded page size or uploading an uncapped file can degrade the service for everyone else. This category also covers cost-based abuse, where an attacker deliberately drives up a target's cloud compute or third-party API billing.
What is Broken Function Level Authorization (API5)?
Distinct from BOLA, this covers cases where a user can access administrative or higher-privilege functions simply because the endpoint doesn't check their role — a regular user calling /api/admin/users/delete and having it succeed because the authorization check was only applied to the admin UI's buttons, not the underlying endpoint. Hidden or undocumented endpoints are a frequent source of this issue, since they're often assumed to be "security by obscurity" and never get an explicit permission check.
What are the remaining risks (API6-API10)?
API6 covers unrestricted access to sensitive business flows (like automated bulk purchasing that bypasses intended human-rate limits). API7 covers server-side request forgery, where an API fetches a user-supplied URL without validating the destination, letting an attacker pivot into internal infrastructure. API8 covers security misconfiguration — permissive CORS policies, verbose error messages leaking stack traces, unpatched components. API9 covers improper inventory management, where old or undocumented API versions stay live and unpatched alongside the current version. API10 covers unsafe consumption of third-party APIs, where an application trusts data or redirects from an integrated third-party service without validating it, effectively inheriting that third party's vulnerabilities.
How do you actually test for these risks?
Traditional SAST and DAST tooling built for web pages misses several API-specific categories because they don't understand API schemas, authorization models, or business logic flows — BOLA in particular requires understanding that two different requests should return different data based on ownership, which is a semantic check, not a pattern match. Effective API security testing combines schema-aware scanning (validating against your OpenAPI spec for excessive data exposure and misconfiguration) with authorization-focused dynamic testing that actually attempts cross-account object access, not just checks for the presence of an auth header.
FAQ
Is the OWASP API Top 10 the same as the OWASP Top 10?
No. The OWASP Top 10 covers general web application risks; the OWASP API Top 10 is a separate, API-specific list focused on authorization, rate limiting, and API design flaws that don't map cleanly onto browser-based vulnerability categories.
What's the difference between BOLA and broken function level authorization?
BOLA is about accessing someone else's specific object (a different user's order); broken function level authorization is about accessing an entire class of functionality you shouldn't have (an admin-only endpoint) regardless of whose object it touches.
How often is the OWASP API Top 10 updated?
It was last substantially revised in 2023, restructuring several 2019 categories. OWASP doesn't run on a fixed annual cycle for this list, so check the current version rather than assuming yearly updates.
Can automated scanners fully cover the OWASP API Top 10?
Automated tools cover most categories well, especially misconfiguration, inventory, and rate-limiting issues, but authorization logic flaws like BOLA often still need targeted testing that understands your specific object ownership model, since a generic scanner can't infer business rules it was never told about.