The OWASP API Security Top 10 (2023)
APIs are how modern software talks to itself, and they have become one of the most attacked surfaces in any application. The OWASP API Security Top 10 is the industry’s shortlist of the risks that matter most, refreshed in 2023 to reflect how attackers actually break APIs today. If you build or buy APIs, this list is the map of where things go wrong.
APIs are how modern software talks to itself, and they have become one of the most attacked surfaces in any application. The OWASP API Security Top 10 is the industry’s shortlist of the risks that matter most, refreshed in 2023 to reflect how attackers actually break APIs today. If you build or buy APIs, this list is the map of where things go wrong.
One pattern jumps out before you even read the details. Authorization, the question of who is allowed to do what, dominates the list.
The top 10, explained
| ID | Risk | What it is |
|---|---|---|
| API1 | Broken Object Level Authorization | Not checking if a user may access a specific object, leaking data or enabling account takeover (IDOR). |
| API2 | Broken Authentication | Weak or missing authentication lets attackers impersonate other users. |
| API3 | Broken Object Property Level Authorization | Not validating access at the property level, exposing or letting users change fields they should not. |
| API4 | Unrestricted Resource Consumption | No limits on compute, memory, or network, enabling denial of service or huge cloud bills. |
| API5 | Broken Function Level Authorization | Not restricting admin or management functions, letting attackers escalate privileges. |
| API6 | Unrestricted Access to Sensitive Business Flows | Exposing business processes without controls, opening them to fraud and automated abuse. |
| API7 | Server Side Request Forgery | Fetching a user-supplied URL unvalidated, tricking the server into reaching internal systems. |
| API8 | Security Misconfiguration | Permissive defaults, unnecessary features, or verbose errors that reveal sensitive information. |
| API9 | Improper Inventory Management | Untracked APIs, versions, and endpoints leaving zombie or shadow APIs exposed. |
| API10 | Unsafe Consumption of APIs | Trusting data from third-party APIs without validation, importing their weaknesses. |
Each entry below is a real failure mode with a real exploit behind it. Read them less as a glossary and more as a checklist of questions to ask about your own APIs.
[[INSIGHT: Three of the top ten risks are the same mistake at different depths: not checking authorization at the object level (API1), the property level (API3), and the function level (API5). APIs hand out data and actions directly, so “did we check whether this caller is allowed” is the question that fails most often and hurts most when it does.]]
- The OWASP API Security Top 10 (2023) lists the ten most critical API risks.
- Broken authorization dominates: API1, API3, and API5 are all authorization failures.
- API1, Broken Object Level Authorization, is the top risk and can lead to account takeover.
- Resource limits (API4) and inventory tracking (API9) are operational, not just code, problems.
- Even trusted third-party APIs are a risk if you consume their data without validating it (API10).
Frequently asked questions
What is the OWASP API Security Top 10?
A list, maintained by OWASP, of the ten most critical security risks for APIs. The 2023 edition runs from Broken Object Level Authorization (API1) to Unsafe Consumption of APIs (API10).
Why is authorization the dominant theme?
Three of the ten risks (API1, API3, API5) are broken authorization at the object, property, and function levels. APIs expose data and actions directly, so failing to check who may do what is the most common and damaging API flaw.
What is Broken Object Level Authorization?
Also called IDOR, it is when an API lets a user act on an object by specifying its identifier without checking they are authorized. It can lead to data disclosure or full account takeover, and it is the top API risk.
What is Unsafe Consumption of APIs?
Blindly trusting and using data from external or third-party APIs without validating it. Since third-party security posture is often unclear, this can import vulnerabilities into your own application.
