OWASP API Security Top 10

What is the OWASP API Security Top 10?

The OWASP API Security Top 10 (often shortened to the OWASP API Top 10) is a framework published by the Open Web Application Security Project (OWASP) that identifies the ten most critical security risks in modern APIs. It is the closest thing the industry has to a shared standard for what API security testing should cover, and it is referenced by regulators, compliance frameworks, and security teams as the baseline for evaluating API risk.

The list was first published in 2019 and significantly updated in 2023 to reflect how API architectures, attack patterns, and abuse techniques had evolved. The 2023 edition introduced new categories around API consumption and server-side request forgery. It also restructured existing categories to better reflect where real-world API breaches were occurring.

Why the OWASP API Security Top 10 exists

APIs are the primary attack surface in modern software. They connect applications, expose data, and handle authentication and authorization across every layer of a system. The vulnerabilities that result from how APIs are designed, implemented, and deployed are structurally different from the vulnerabilities that affect traditional web applications, and so are the API attacks that exploit them. Therefore, the tools and techniques built for web application testing do not reliably detect them.

The OWASP API Security Top 10 exists to name and classify these risks in a way that security teams, developers, and auditors can act on. Without a shared taxonomy, API security testing has no agreed baseline. With it, organizations can define what coverage means, what testing should prove, and what gaps remain.

The attack surface is also growing in a new direction. AI agents increasingly call APIs autonomously, at machine speed and volume, to retrieve data and trigger actions on a user’s behalf. They can exercise an API far faster and less predictably than a human, often with broad authorization.

That amplifies OWASP Top 10 risks, particularly Unrestricted Resource Consumption, BOLA, and the abuse of sensitive business flows. APIs exposed to AI agents need those controls tested under that load.

The OWASP API Security Top 10 categories (2023 edition)

Each of the 10 categories below describes a distinct class of API risk, ordered by the OWASP project according to a combination of prevalence, exploitability, and impact.

API1:2023 - Broken Object Level Authorization (BOLA)

The most prevalent and consistently exploited API vulnerability. An API exposes object identifiers - user IDs, order numbers, or account references - and fails to perform the authorization checks that verify the requesting user is allowed to access the specific object they are requesting. Attackers enumerate these identifiers to access sensitive information belonging to other users.

BOLA does not require bypassing authentication. It exploits the gap between authentication (who you are) and authorization (what you are allowed to access).

API2:2023 - Broken Authentication

Weaknesses in how an API authenticates requests, including

• Poorly implemented token validation
• Missing expiry controls
• Insecure transmission of credentials, such as API keys
• Authentication flows that can be bypassed through manipulation of request parameters or headers, or worn down by brute force attacks against weak credentials

API3:2023 - Broken Object Property Level Authorization

An evolution of both BOLA and excessive data exposure. An API returns more properties of an object than the requesting user should see, or accepts property-level updates that the user should not be permitted to make, resulting in unauthorized access to sensitive fields.

Attackers use this to read sensitive fields or modify data they have no business access to.

API4:2023 - Unrestricted Resource Consumption

An API imposes no meaningful limits on the rate, volume, or computational cost of requests. Attackers exploit this to conduct denial of service attacks, enumerate data at scale, or exhaust backend resources. They often do that without triggering standard security controls because each request appears legitimate.

API5:2023 - Broken Function Level Authorization (BFLA)

An API exposes administrative or privileged functions to users who should not have access to them. Unlike BOLA, which concerns data objects, BFLA concerns actions.

An attacker calls an endpoint that should be restricted to administrators or accesses functionality that the application interface never presents to them because the API applies no authorization checks at the function level. The failure is one of missing access controls on privileged actions.

API6:2023 - Unrestricted Access to Sensitive Business Flows

An API exposes business-critical workflows - account creation, checkout, password reset, or loyalty point redemption - without adequate controls on how they can be automated or abused. Attackers use these flows for credential stuffing, inventory abuse, fraud, and scalping.

The risk is not a code vulnerability. It is the absence of business logic controls on legitimate-looking API traffic, which is precisely what makes this threat hard to detect through standard monitoring.

API7:2023 - Server-Side Request Forgery (SSRF)

An API accepts a URL or network location as input and makes server-side outbound requests to it without sufficient validation. Attackers use this to reach internal services, cloud metadata endpoints, and backend systems that should never be reachable from the public internet.

API8:2023 - Security Misconfiguration

Incorrect or absent security settings across the API stack:

• Permissive CORS policies
• Verbose error messages that expose implementation details
• Missing transport security
• Weak or absent access controls
• Unnecessary HTTP methods left enabled
• Default credentials or configurations left in place.

Security misconfiguration is consistently one of the most commonly observed issues across API security assessments because it emerges not from deliberate design decisions but from gaps in deployment and configuration review.

API9:2023 - Improper Inventory Management

An organization does not maintain an accurate, complete API inventory, including:

• Deprecated versions
• Internal APIs exposed externally
• APIs introduced through third-party integrations
• Services that were built for one purpose and remained accessible after that purpose ended

Attackers target deprecated and undocumented APIs precisely because they are less likely to be monitored or maintained, making them an easy route to unauthorized access. This category is the formal recognition that shadow APIs are unmanaged API assets, meaning a structural risk category rather than an edge case.

API10:2023 - Unsafe Consumption of APIs

An application trusts data received from third-party APIs without adequate validation, treating external API responses as inherently safe. Attackers compromise or manipulate a third-party API to inject malicious data into a downstream application that consumes it without inspection, turning a trusted integration into a threat.

How the OWASP API Security Top 10 is used in practice

Security teams use the OWASP API Top 10 as a coverage framework, that is, a checklist of what an API security testing program should be able to demonstrate it has assessed. Compliance frameworks reference it as a testing standard, and regulators increasingly expect organizations in regulated industries to evidence coverage against it.

Used correctly, the OWASP API Top 10 defines the minimum scope of an API security assessment, not the ceiling. Not every category applies equally to every API, and the most consequential vulnerabilities in a given environment are not always the ones that score highest on a generic severity scale.

The list is a starting point for defining what to test, not a substitute for testing that is contextual, adversarial, and specific to how a given API is actually designed and deployed.

The limitation of purely framework-driven testing is that the OWASP API Security Top 10 describes vulnerability classes, not individual vulnerabilities. An organization can confirm that it has tested against every category and still have exploitable risks in its environment.

That particularly applies to the business logic and authorization categories, where the flaw is specific to how the application works rather than a generic pattern a scanner can match.

OWASP API Security Top 10 and continuous penetration testing

Traditional penetration testing can assess coverage against the OWASP API Security Top 10 at the point in time when the test runs. The limitation is that APIs change continuously, and a point-in-time assessment does not remain accurate for long.

Continuous penetration testing validates coverage against the OWASP API Security Top 10 on an ongoing basis, so that every material change to an API surface is tested rather than waiting for the next scheduled engagement. In a continuous model, the Top 10 functions as a permanent test specification instead of a periodic checklist.

This matters particularly for the categories that are most sensitive to change, such as API9 (Improper Inventory Management) and API1 (BOLA), because the risk they describe grows directly with the rate at which APIs are modified, deprecated, and introduced, and the API inventory drifts out of date.

OWASP API Security Top 10 and compliance

Several regulatory frameworks now reference API security testing explicitly or implicitly through requirements for continuous security validation:

• DORA requires financial entities to conduct regular and rigorous testing of their ICT systems. API security testing against the OWASP Top 10 is a substantive component of demonstrating that requirement in practice.
• PCI DSS v4.0 requires penetration testing that covers APIs handling cardholder data, with explicit expectations around authorization testing that map directly to BOLA and BFLA.
• NIS2 requires both essential and important entities to implement appropriate technical measures to manage security risks, including security testing of systems, of which APIs are a central component in most modern environments.
• ISO 27001 requires organizations to monitor, measure, and evaluate the effectiveness of their information security management system and its controls. API security testing provides direct evidence of control effectiveness in environments where APIs handle sensitive data or critical business functions.

OWASP API Security Top 10 coverage with Equixly

Equixly tests all ten OWASP API Security Top 10 categories continuously and adversarially. And it does that not by matching requests against signatures, but by reasoning about how each API is designed and probing the specific authorization, authentication, and business logic controls in place.

For the categories that require contextual, multi-step testing - BOLA, BFLA, and Unrestricted Access to Sensitive Business Flows in particular - Equixly’s approach goes beyond what automated scanners are built to find. The platform chains API calls across services and tests business logic the way a real attacker approaches it.

Every finding is exploit-validated before it surfaces to the security team. Coverage against the OWASP API Security Top 10 is continuous, so the evidence it produces reflects the current state of the API rather than a snapshot from the last engagement.