OWASP API Top 10 2023: What Changed and How to Defend

The OWASP API Top 10 2023 is a ranked list of the ten most critical API security risks, and its defining feature is that authorization failures, not injection, dominate the top of the list. Broken Object Level Authorization sits at number one, exactly where it was in the 2019 edition, because APIs expose object identifiers directly and enforcement is easy to get wrong. If you build or defend APIs, this is the reference to design your controls around.

The 2023 revision refined the 2019 list rather than rewriting it. Some categories merged, two genuinely new risks appeared, and the ordering shifted to match what breach data actually showed. Below is the complete list of OWASP top 10 vulnerabilities 2023 for APIs, with the defense that matters most for each.

The full list

Here are the top 10 OWASP vulnerabilities 2023 for API security, in order:

1. API1: Broken Object Level Authorization (BOLA) — an endpoint returns an object without checking the caller is allowed to see that specific object.
2. API2: Broken Authentication — weak or missing verification of who the caller is.
3. API3: Broken Object Property Level Authorization — a merger of two 2019 categories, covering excessive data exposure and mass assignment at the property level.
4. API4: Unrestricted Resource Consumption — no limits on rate, payload size, or expensive operations, enabling denial of service and cost inflation.
5. API5: Broken Function Level Authorization — a user reaches admin or privileged functions they should not.
6. API6: Unrestricted Access to Sensitive Business Flows — automation abuses a legitimate flow (buying tickets, posting comments) at scale.
7. API7: Server Side Request Forgery (SSRF) — the API fetches a user-supplied URL, letting an attacker reach internal systems.
8. API8: Security Misconfiguration — insecure defaults, verbose errors, missing headers, open CORS.
9. API9: Improper Inventory Management — forgotten, undocumented, or stale API versions and hosts.
10. API10: Unsafe Consumption of APIs — trusting data from third-party APIs without validation.

Why authorization leads the list

The three authorization categories (API1, API3, API5) are the heart of the 2023 edition. Injection, which topped web application lists for years, is not even a standalone API category here. The reason is structural: APIs are consumed by other software, so the object IDs and parameters that a browser UI would hide are right there in the request. An attacker changes /api/orders/1024 to /api/orders/1025 and, if the server only checks that you are logged in rather than that this order is yours, you read someone else's data.

The defense for BOLA is to enforce object ownership on every request, at the data layer, using the authenticated identity from the token rather than any ID in the request path or body. Never trust a client-supplied ID to also imply permission.

The genuinely new risks

Two categories in the 2023 list did not exist in 2019 and reflect how attacks evolved.

API6, Unrestricted Access to Sensitive Business Flows, is about abuse of functionality that works exactly as designed. Think of scalping bots buying an entire concert allocation in seconds, or bulk account creation to farm promotions. There is no injection and no broken auth; the flow just was not built to resist automation. Defenses are behavioral: device fingerprinting, rate anomaly detection, and CAPTCHA or proof-of-work on flows that are expensive to abuse.

API10, Unsafe Consumption of APIs, flips the usual perspective. Instead of attacks against your API, it covers what happens when your API trusts a third-party API's response too much. If you ingest data from an integration partner and feed it into a database query or render it without validation, a compromise of that partner becomes a compromise of you. Treat every upstream response as untrusted input.

Mapping the list to your pipeline

Knowing the categories is step one; catching them before release is step two. Different risks are caught by different tooling:

• Design and code review catch BOLA and function-level authorization gaps, because they are logic flaws no scanner fully understands.
• DAST exercises a running API and finds SSRF, misconfiguration, and some authorization issues by actually sending crafted requests.
• API inventory tooling addresses API9 by discovering endpoints you forgot you shipped.

Combine them. A running-application scanner will not know that order 1025 belongs to a different tenant, and a code review will not notice that a load balancer is leaking a stack trace. If you want to build this into a team's habits, our security academy walks through testing each category hands-on.

A defense checklist per category

For teams operationalizing the OWASP top 10 vulnerabilities 2023:

• Enforce per-object authorization at the data layer (API1, API3, API5).
• Use short-lived tokens and validate them on every request (API2).
• Apply rate limits, payload caps, and timeouts on expensive operations (API4).
• Add behavioral controls to high-value business flows (API6).
• Allowlist outbound URLs and block internal address ranges (API7).
• Ship hardened defaults and strip verbose errors in production (API8).
• Maintain a live API inventory tied to deployment (API9).
• Validate and schema-check every third-party API response (API10).

FAQ

What is the top risk in the OWASP API Top 10 2023?

Broken Object Level Authorization (BOLA), API1. An endpoint returns an object without verifying the authenticated caller is allowed to access that specific object. It held the top spot from the 2019 edition.

What changed from the 2019 OWASP API list?

Two new categories appeared: Unrestricted Access to Sensitive Business Flows (API6) and Unsafe Consumption of APIs (API10). Several older categories merged, notably excessive data exposure and mass assignment into Broken Object Property Level Authorization (API3).

Is injection in the OWASP API Top 10 2023?

Not as a standalone category. Injection risks are folded into other categories, and the 2023 list is dominated by authorization failures instead, reflecting how API breaches actually occur.

How do I test my API against this list?

Combine code review and design analysis for authorization logic with dynamic scanning (DAST) for SSRF and misconfiguration, plus API inventory tooling to find forgotten endpoints. No single technique covers all ten categories.