OWASP API Security Top 10 (2026): The List, Explained
Written by the Rafter Team
If you are searching for the "OWASP API Security Top 10 2026," here is the direct answer: it does not exist yet. The current and only official edition is the OWASP API Security Top 10:2023, a standalone list maintained separately from the general OWASP Top 10, and it is still the version every API security program should be building against. It ranks ten API-specific risks, led by Broken Object Level Authorization, or BOLA, where an API hands back or modifies data belonging to another user because it never checks whether the caller actually owns the object being requested.
This guide walks through all ten 2023 categories, shows how the list differs from the web-focused OWASP Top 10, and gives concrete mitigations for each risk. The short version: the API list is authorization-heavy in a way the web list is not, because APIs expose direct, machine-callable access to objects and business functions that used to sit behind a browser's UI. That difference changes where your review effort should go.
Five of the ten categories on this list are variations on the same root cause: a request reaches the API, and nothing on the server checks whether the caller was actually allowed to do what they just did. Object-level, function-level, and property-level authorization failures are the categories security teams and API vendors report most often in practice, which is why this list reads so differently from the web OWASP Top 10.
The Quick Verdict
There is no "2026 edition." OWASP API Security Top 10:2023 is current, and it was last updated in 2023 after the original 2019 release. If a source claims a newer edition, it is describing vendor commentary, not an official OWASP publication.
Here is the full list, in order:
| Rank | Category | One-line risk |
|---|---|---|
| API1:2023 | Broken Object Level Authorization (BOLA) | The API returns or edits another user's data because it never checks object ownership. |
| API2:2023 | Broken Authentication | Weak, missing, or misimplemented auth lets attackers impersonate users or forge tokens. |
| API3:2023 | Broken Object Property Level Authorization (BOPLA) | An endpoint exposes or lets callers write fields they should never see or change. |
| API4:2023 | Unrestricted Resource Consumption | No limits on request size, rate, or cost let one client exhaust or bankrupt the API. |
| API5:2023 | Broken Function Level Authorization (BFLA) | A regular user can call an admin-only endpoint because role checks are missing. |
| API6:2023 | Unrestricted Access to Sensitive Business Flows | Automatable flows like purchases or referrals get abused at scale with no friction. |
| API7:2023 | Server-Side Request Forgery (SSRF) | The API fetches a URL supplied by the caller, reaching internal systems it should not. |
| API8:2023 | Security Misconfiguration | Default settings, verbose errors, or open CORS policies leak more than intended. |
| API9:2023 | Improper Inventory Management | Old, undocumented, or shadow API versions stay live and unmonitored. |
| API10:2023 | Unsafe Consumption of APIs | The app trusts data from a third-party API without validating or sanitizing it. |
What Is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a project run by the Open Worldwide Application Security Project, the same nonprofit behind the general OWASP Top 10, but it is a distinct working group with its own release cycle. It first shipped in 2019 and was substantially rewritten in 2023 based on real incident data and community input on how modern API architectures actually get attacked.
The project exists because APIs behave differently from traditional web applications. A browser-rendered page hides most of an application's internal structure behind HTML and JavaScript, but an API publishes its structure directly, which turns authorization logic into the primary line of defense instead of a secondary one.
The OWASP API Security Top 10 (2023), Explained
API1:2023 — Broken Object Level Authorization
BOLA happens when an API checks that a request is authenticated but not that the user actually owns the object being requested. Changing /orders/1042 to /orders/1043 and getting back someone else's order is the textbook case, and it is consistently the most reported API vulnerability in the wild. Fix it with an ownership check on every object-returning endpoint, enforced through a shared authorization layer rather than reimplemented per route, and tests that assert cross-user access fails.
API2:2023 — Broken Authentication
This category covers weak password policies, improperly verified tokens, unthrottled credential stuffing, and API keys that never expire. Attackers do not need to break cryptography when an authentication endpoint simply skips basic controls. Fix it with a vetted identity provider instead of custom token logic, short-lived tokens with rotation, and rate limiting on authentication endpoints specifically.
API3:2023 — Broken Object Property Level Authorization
BOPLA merges two 2019-list risks: excessive data exposure, where a response includes fields the client should not see, and mass assignment, where a request lets the caller set fields it should not touch, such as role or isAdmin. Returning a full user object for a display name is the exposure half; accepting that object back on update is the mass-assignment half. Fix both with an explicit allowlist of readable and writable properties per endpoint.
API4:2023 — Unrestricted Resource Consumption
APIs that do not cap request size, response size, execution time, or call rate leave the door open to denial of service and unexpected cloud bills alike. An endpoint with an unbounded limit parameter joining across tables can be enough to degrade the whole service. Fix it with explicit limits on every dimension, per-client rate limiting, and cost monitoring on paid third-party calls.
API5:2023 — Broken Function Level Authorization
BFLA is the function-level sibling of BOLA: the object-ownership check might be fine, but nothing verifies the caller's role before running an administrative function. A regular user account calling POST /admin/users/delete and having it succeed is the classic failure. Fix it with centralized role checks at the routing or middleware layer, not scattered inline conditionals that get missed as endpoints are added.
API6:2023 — Unrestricted Access to Sensitive Business Flows
This newer, business-logic-focused category covers a well-authorized flow abused at scale, such as buying limited inventory in bulk, scraping prices, or farming referral bonuses. The vulnerability is not a broken permission check; it is the absence of any control on how often a legitimate action can be repeated. Fix it with device fingerprinting, friction at the right steps, and business-rule-aware rate limiting rather than generic throttling.
API7:2023 — Server-Side Request Forgery
SSRF occurs when an API accepts a URL from the caller and fetches it server-side, letting an attacker reach internal services and cloud metadata endpoints the API server can see but the attacker cannot. Webhook registration and "import from URL" features are common entry points. Fix it by allowlisting destination hosts, blocking requests to internal IP ranges by default, and disabling URL-fetching features that are not core to the product.
API8:2023 — Security Misconfiguration
This is the same broad category as on the web Top 10, applied to API infrastructure: permissive CORS policies, verbose stack traces, default credentials on management interfaces, and unpatched components. Misconfiguration is common precisely because it requires no code change, just one unreviewed setting. Fix it with a hardened, repeatable deployment baseline, automated configuration scanning, and removing debug modes before production.
API9:2023 — Improper Inventory Management
Teams that cannot enumerate every API version and endpoint they run cannot secure what they do not know exists. A deprecated v1 endpoint left reachable after v2 ships, with none of the newer protections applied, is a routine finding in real audits. Fix it with a living inventory of hosts and versions and a schedule for deprecating old ones.
API10:2023 — Unsafe Consumption of APIs
This category flips the usual direction: it covers the risk an application takes on by trusting data from the third-party and partner APIs it calls, rather than risk from its own endpoints. Blindly following a response's redirects or deserializing its payload without validation can pull an attacker-controlled path back into your own systems. Fix it by treating every upstream API response as untrusted input, validated and sanitized the same way you would treat user input.
OWASP API Security Top 10 vs. OWASP Top 10: What's Different
The two lists share a publisher but not a center of gravity. The general OWASP Top 10 spreads risk across access control, misconfiguration, the supply chain, cryptography, injection, and design, since a web app's attack surface includes rendering and sessions with a browser between the user and the server. The API list concentrates instead on authorization and business logic, since an API is the direct interface, and no browser layer absorbs any of the risk.
| Dimension | OWASP Top 10 (web) | OWASP API Security Top 10 |
|---|---|---|
| Current edition | 2025 | 2023 |
| Dominant failure mode | Spread across ten distinct categories | Authorization and business logic (5 of 10 categories) |
| Broken access control | One category (A01), covers all access control including SSRF | Split across BOLA, BFLA, BOPLA, and sensitive business flows |
| SSRF | Folded into Broken Access Control (A01) | Its own category (API7), reflecting how often APIs fetch caller-supplied URLs |
| Injection | Its own top-five category (A05) | Not a standalone category; covered implicitly under misconfiguration and unsafe consumption |
| Primary audience | Anyone building a server-rendered or browser-facing app | Teams building or consuming machine-to-machine interfaces |
Roughly half the API list is authorization by another name: BOLA is object-level, BFLA is function-level, BOPLA is property-level, and unrestricted business-flow access is authorization applied to a sequence of calls rather than one. The web Top 10 folds all of that into a single category, A01 Broken Access Control. An API-heavy team should treat broken access control as the seed concept, then read the API list as four different lenses on the same underlying failure.
Where This Shows Up in AI-Built APIs
AI coding agents are prolific at generating CRUD endpoints—the create, read, update, and delete operations behind most APIs—and they tend to replicate whatever authorization pattern already exists, including a missing one. If the first endpoint never checks object ownership, an agent asked to add five more will often copy that gap five more times, which is how BOLA and BFLA findings multiply across a fast-moving API surface. Hardcoded credentials follow the same pattern: agents scaffolding a working example frequently leave a real key in the sample code, one reason exposed API keys show up so often in agent-generated repositories.
The inventory problem compounds this, since an agent that generates a new API version rarely updates a central catalog of what exists. Secrets management for the tokens those agents handle deserves its own scrutiny, which is why AI agent data leakage and secrets management is worth reading alongside this list.
How to Defend Against the OWASP API Top 10 in Practice
Start with authorization, since it is the through-line across five of the ten categories. Every endpoint that returns or modifies an object should carry an ownership check, every administrative function should carry a role check, and both should be tested with a request from a second, unauthorized account.
Pair static review with tests that exercise a running API. Static analysis catches missing checks and unsafe patterns before merge, while a dynamic scanner like the one covered in Getting Started with OWASP ZAP probes a running instance for the access-control and misconfiguration issues that only appear at runtime. Neither replaces the other; BOLA, BFLA, and misconfiguration all benefit from both angles.
Inventory and dependency hygiene close out the list. Keep a living catalog of every API version, and extend the same discipline to the third-party APIs you consume, since unsafe consumption is a supply-chain problem in miniature; the practices in Dependency Scanning and SCA: The Complete Guide apply as well to the APIs you call as to the packages you import.
Rafter runs a security review in CI on every pull request—static analysis, software composition analysis, and secret scanning—so missing authorization checks and hardcoded keys in new API code surface before merge instead of after an incident. Security for a world where agents write the code means catching what they copy, not just what they write.
Conclusion
The OWASP API Security Top 10:2023 is the current list, and the honest read of it is that authorization is the job. Five of ten categories are authorization by another name, which is a different emphasis than the browser-facing OWASP Top 10 and a good reason to review API code with object-, function-, and property-level checks specifically in mind.
The practical next step is to audit your highest-traffic endpoints against BOLA and BFLA first, since they are both the most common findings and the cheapest to test for directly.
Frequently Asked Questions
What is the OWASP API Security Top 10 2026?
There is no 2026 edition. The current and only official version is the OWASP API Security Top 10:2023, released in 2023 and still the active standard as of this writing. People search "2026" because they want the current list, and the 2023 edition is that list.
How is it different from the OWASP Top 10?
The general OWASP Top 10 covers browser-facing web application risk broadly, spreading across access control, misconfiguration, cryptography, injection, and supply-chain issues. The API Security Top 10 is narrower, and roughly half its categories are variations on authorization, since APIs expose objects and functions directly with no browser layer in between.
What is BOLA?
BOLA, or Broken Object Level Authorization, is when an API checks that a caller is authenticated but never verifies that the caller actually owns the object being requested. It is the most consistently reported API vulnerability across audits and breach reports, and it usually looks as simple as changing an ID in a request and getting back someone else's data.
Is there a 2026 edition?
No. OWASP labels editions by release year, and the most recent is 2023, following the original 2019 release. The project is revised roughly every three to four years based on contributed incident data, so a future edition will carry whatever year it actually publishes in.
Do I need to worry about both lists, or just one?
Most teams need both. The general OWASP Top 10 covers browser-facing and infrastructure risk common to any web application, while the API list covers the authorization and business-logic risk specific to how your API is called. If your product has both a web front end and an API, both lists apply to different parts of the same system.