If you secure APIs, the OWASP API Security Top 10 is the map you start from. It is the industry reference for the risks that actually break APIs in production, and it looks nothing like the general OWASP Top 10 for web applications, because APIs fail in their own way.
This guide walks all ten categories of the current 2023 edition, explains what changed from the 2019 list, and grounds each risk in a real CVE so you can see it in working code rather than in the abstract. Where a category maps to a finding from our own API penetration testing research, the link goes straight to the proof.
What is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a community-built list, published by the Open Worldwide Application Security Project, of the most serious security risks specific to APIs. It exists because APIs face a different threat profile from traditional web applications, so the general OWASP Top 10 does not capture how they actually get breached.
The list was first released in 2019 and updated in 2023, and the 2023 edition is the current reference. Each entry describes a class of weakness, why it is dangerous, and how to defend against it, and together they cover the patterns that show up in the majority of real API incidents.
The single most important thing the list tells you is where to look first. Most API breaches are authorization failures, not exotic exploits, and three of the ten categories are authorization risks. If you fix nothing else, fix those.
The OWASP API Security Top 10 (2023) at a glance
Rank | Category | The one-line version |
|---|---|---|
API1:2023 | Broken Object Level Authorization | An endpoint returns or changes a record without checking the caller owns it |
API2:2023 | Broken Authentication | Identity can be forged through weak or missing token validation |
API3:2023 | Broken Object Property Level Authorization | The caller reads or writes object fields they are not entitled to |
API4:2023 | Unrestricted Resource Consumption | No limits on requests or payloads, enabling abuse and denial of service |
API5:2023 | Broken Function Level Authorization | Privileged actions with no server-side role check |
API6:2023 | Unrestricted Access to Sensitive Business Flows | A business flow can be automated and abused at scale |
API7:2023 | Server Side Request Forgery | The API fetches a caller-supplied URL and reaches internal systems |
API8:2023 | Security Misconfiguration | Insecure defaults, verbose errors, and missing hardening |
API9:2023 | Improper Inventory Management | Forgotten, undocumented, or unversioned endpoints |
API10:2023 | Unsafe Consumption of APIs | Third-party API responses trusted without validation |
What changed in the 2023 edition
Three changes are worth knowing if you are moving from the 2019 list.
First, the old Excessive Data Exposure and Mass Assignment categories were merged into a single risk, API3:2023 Broken Object Property Level Authorization. OWASP recognized that they are two directions of the same defect. One reads fields the caller should not see, and the other writes fields the caller should not set.
Second, two categories were added. Unrestricted Access to Sensitive Business Flows (API6) covers automated abuse of legitimate flows, such as bulk-buying limited stock or mass-creating accounts. Unsafe Consumption of APIs (API10) covers the risk of trusting data from the third-party APIs your application depends on.
Third, the framing sharpened around authorization. The 2023 list makes clear that object-level, property-level, and function-level authorization are three distinct failures, and that most severe API bugs live in one of the three.
API1:2023 Broken Object Level Authorization (BOLA)
BOLA is the most common and most damaging API vulnerability, which is why it sits at the top. An endpoint takes an object id, fetches the record, and returns it without confirming the caller is allowed to access that specific object. Change the id in the request, and you get someone else's data.
When the identifier is predictable and user-supplied, the same flaw is often called an IDOR vulnerability, an insecure direct object reference. In multi-tenant SaaS, BOLA is catastrophic, because a query that trusts a client-supplied tenant id can hand one customer another customer's records.
CVE-2026-71505 is a textbook case. A portal endpoint let a low-privileged caller modify an account they did not own, by supplying its id, because the write path never checked ownership. The result was full account takeover through a single object reference.
How to prevent it. Enforce ownership on every object-scoped request, checked server-side at the data layer, and never rely on the client to send a correct or honest id.
API2:2023 Broken Authentication
Authentication establishes who is calling. When it is weak, an attacker forges identity and everything downstream collapses. This covers missing token validation, tokens that never expire, weak or predictable secrets, credential stuffing with no rate limit, and algorithm confusion in signed tokens.
The impact is usually full account takeover, because a forged or stolen token is treated as a legitimate one. Authentication flaws often pair with credential exposure, where a related flaw leaks the material an attacker needs to authenticate as someone else.
How to prevent it. Validate token signatures and algorithms strictly, enforce short expiry and rotation, rate-limit authentication endpoints, and never accept authentication state the client can influence.
API3:2023 Broken Object Property Level Authorization
This risk covers the two failures the 2023 edition merged, and it is worth taking both directions in turn, because each has a distinct fix.
Excessive data exposure is the read side. An endpoint returns more fields than the caller should see, usually because the response is serialized straight from the database object with no field-level filter. CVE-2026-71511 is a stark example, where a member card returned a live bcrypt password hash to any account with read-members rights. CVE-2026-71510 is the subtler version, where a filter parameter let a caller read salary and password columns one bit at a time from an endpoint that strips those fields from its normal responses.
Mass assignment is the write side. An endpoint copies request-body fields onto a record with no allow-list, so a caller sets attributes they were never meant to control. CVE-2026-71504 let an unfiltered assignment loop set a linked user's password and reach administrator. The same shape recurs in CVE-2026-71508, where an employee sets their own salary, and CVE-2026-71509, where a filer approves their own expense claim by writing the workflow fields directly. Read our full breakdown of the mass assignment vulnerability for the pattern in depth.
How to prevent it. Return only the fields a caller may see, redacted structurally in a shared serializer, and accept only the fields a caller may write, through an allow-list per privilege tier.
API4:2023 Unrestricted Resource Consumption
APIs cost resources to serve, and an API that does not limit consumption invites abuse. Missing rate limits enable brute force and mass extraction. Missing payload and pagination limits enable denial of service and bulk scraping. Unbounded operations that trigger expensive backend work can be weaponized into a resource-exhaustion attack.
How to prevent it. Enforce rate limits per client and per endpoint, cap payload size and page size, and put timeouts and quotas on any operation that consumes significant backend resources.
API5:2023 Broken Function Level Authorization
Where BOLA is about objects, this is about actions. A privileged operation, an admin function, a state change, a bulk export, is exposed through an endpoint that never checks the caller holds the right to perform it. The object-level check may pass while the function-level check is simply absent or wrong.
CVE-2026-71506 shows the wrong-check version, where a payment-deletion route validated a permission, but the wrong one, so a caller who could edit invoices could delete payments. CVE-2026-71509 shows the missing-check version, where a generic update route reached approval fields that a dedicated approve permission was meant to govern.
How to prevent it. Check the caller's role on every privileged action, server-side, and deny by default, so a route that forgets to check refuses rather than allows.
API6:2023 Unrestricted Access to Sensitive Business Flows
New in 2023, this risk is not about a single request but about a flow. A business process that is safe when a human performs it once becomes harmful when an attacker automates it, such as buying all of a limited product, mass-creating accounts, or flooding a comment system. The individual requests are valid. The abuse is in the volume and the intent.
How to prevent it. Identify the flows an attacker would want to automate, and defend them with device fingerprinting, rate and velocity limits, and human-verification challenges where the flow is sensitive.
API7:2023 Server Side Request Forgery
SSRF happens when an API fetches a resource from a caller-supplied URL without validating it. An attacker points the API at internal systems, cloud metadata endpoints, or other services the API can reach but the attacker cannot, turning the server into a proxy into the internal network.
How to prevent it. Validate and allow-list any URL the server will fetch, block requests to internal address ranges and metadata endpoints, and never send raw error responses from the fetch back to the caller.
API8:2023 Security Misconfiguration
This is the broad category of insecure settings. Verbose error messages that leak stack traces and schema, missing security headers, permissive CORS, unpatched components, default credentials, and debug features left on in production all live here. Each is individually simple and collectively common.
How to prevent it. Harden every environment to a repeatable baseline, suppress internal detail in error responses, keep components patched, and remove debug and default settings before production.
API9:2023 Improper Inventory Management
You cannot secure what you do not know exists. This risk covers forgotten endpoints, undocumented routes, deprecated versions still serving traffic, and non-production hosts exposed to the internet. Old API versions are especially dangerous, because they often lack the fixes the current version received.
How to prevent it. Maintain an accurate inventory of every endpoint and version, retire deprecated routes on a schedule, and keep documentation generated from the running code rather than maintained by hand.
API10:2023 Unsafe Consumption of APIs
Also new in 2023, this risk flips the perspective. Your API consumes other APIs, and if it trusts their responses without validation, a compromise or a malicious response upstream becomes a vulnerability in your system. Developers tend to validate user input carefully and third-party responses hardly at all.
How to prevent it. Treat data from third-party APIs with the same suspicion as user input, validate it against a schema, and isolate the failure so a bad upstream response cannot corrupt your own data.
How to test for the OWASP API Top 10
Knowing the list is the start. Confirming your API is free of these flaws is the work, and it follows a staged methodology, from endpoint enumeration through authorization testing to a proven exploit. Our API penetration testing guide walks the full process, and the API penetration testing checklist turns this list into a concrete pass you can run.
The authorization risks, API1, API3, and API5, are the ones that most reward code-aware testing, because they live in logic that traffic-based scanners cannot see. A scanner can tell an endpoint exists. It usually cannot tell that the endpoint returns a record without checking who owns it, which is exactly the gap the OWASP list keeps pointing at.
Conclusion
The OWASP API Security Top 10 is the clearest signal in the industry about where API risk concentrates, and the signal is loud. Authorization failures dominate, they are exploitable from the outside with nothing more than a valid account and the right endpoint, and they need code context to find reliably.
That is the model CodeAnt AI runs. It reads your codebase, maps every endpoint, and tests each one against these risk classes with full code context, proving each finding with a working exploit rather than a signature match. The nine Dolibarr CVEs linked throughout this guide are what that produces. See the offensive side on the pentesting page, or browse the vulnerability database behind it.
Is the OWASP API Security Top 10 the same as the OWASP Top 10?
No. The general OWASP Top 10 covers web application risks broadly, while the OWASP API Security Top 10 is specific to APIs and reflects how they actually get breached, with far more emphasis on authorization and far less on classic injection.
The OWASP API Top 10 Is a Checklist. Your API Needs a Proof.
The OWASP API Security Top 10 tells you where APIs break. It does not tell you whether your implementation is actually exploitable. The highest-risk categories like: BOLA, broken property authorization, and broken function authorization, often look correct until someone follows an object across roles, changes the identifier, writes a field the UI never exposes, or carries a manipulated value into the next business step.
That is why API security testing cannot stop at endpoint discovery or severity scores. The useful finding is the one you can reproduce.
If you want to know whether your API actually fails the OWASP Top 10, test the paths an attacker can prove, not just the patterns a scanner can recognize.
→ Explore CodeAnt AI's API penetration testing today!
Related reading
API penetration testing: the complete guide, the pillar this framework sits inside.
Mass assignment vulnerability explained, the write side of API3.
API penetration testing case study: nine findings in one ERP, real CVEs across these categories.
