OWASP API Security Top 10

Why It Matters

The OWASP API Security Top 10 is the most widely referenced framework for API vulnerability classification. Security teams use it to structure API penetration testing engagements. Developers use it to validate their API designs against known risk patterns. Compliance frameworks increasingly reference it as a benchmark for API security posture.

Unlike the traditional OWASP Top 10 for web applications, the API-specific list focuses on the unique risks that arise when business logic is exposed through programmatic interfaces. APIs face distinct threats because they operate without the constraints of a user interface, accept structured data from any client, and often expose more functionality than intended.

The 2023 OWASP API Security Top 10

API1: Broken Object Level Authorization

The most common API vulnerability. It occurs when an API does not verify that the requesting user has permission to access a specific object (resource). An attacker changes an identifier in the request, such as a user ID or order number, and the API returns data belonging to another user.

API2: Broken Authentication

Weaknesses in authentication mechanisms that allow attackers to compromise tokens, keys, or passwords, or exploit implementation flaws to assume other users' identities. Covers issues like weak token generation, missing token expiration, insecure password reset flows, and credential stuffing without rate limiting.

API3: Broken Object Property Level Authorization

Combines two related problems: excessive data exposure (API returns more fields than the frontend needs) and mass assignment (API accepts fields the user should not be able to modify). Both stem from failing to validate which properties a user should read or write.

API4: Unrestricted Resource Consumption

APIs that do not properly limit the resources a single request or user can consume. Covers missing or misconfigured rate limiting, pagination without bounds, large payload acceptance, and expensive operations without throttling.

API5: Broken Function Level Authorization

Users accessing API functions reserved for other roles. A regular user calling admin endpoints, for example. Differs from BOLA in that it concerns which actions a user can perform rather than which objects they can access.

API6: Unrestricted Access to Sensitive Business Flows

New in 2023. APIs that expose sensitive business flows (purchasing, booking, commenting) without controls to prevent automated abuse. Covers scenarios like ticket scalping bots, automated account creation, and mass coupon redemption.

API7: Server-Side Request Forgery (SSRF)

New in 2023. APIs that fetch remote resources based on user-supplied URLs without validating or restricting the destination. Allows attackers to force the server to make requests to internal services, cloud metadata endpoints, or other unintended targets.

API8: Security Misconfiguration

Missing security hardening, permissive CORS policies, verbose error messages, unnecessary HTTP methods enabled, missing TLS, and exposed debug endpoints. Covers the infrastructure and configuration layer surrounding APIs.

API9: Improper Inventory Management

Organizations losing track of which API versions are deployed, which endpoints are exposed, and which documentation is accessible. Old API versions running without patches, shadow APIs, and exposed Swagger/OpenAPI documentation all fall under this category.

API10: Unsafe Consumption of Third-Party APIs

APIs that trust data received from third-party services without proper validation. When an application integrates external APIs and processes their responses without sanitization or verification, it inherits the security posture of those external services.

How to Use the OWASP API Top 10

For beginners, focus on API1 through API5 first. These five categories cover the majority of real-world API security findings and teach the fundamental testing mindset: verify authentication, verify authorization, inspect data exposure, and test resource limits.

Use the list as a checklist during API security assessments. For each endpoint, ask: Is object-level access controlled? Is authentication properly enforced? Does the response contain excessive data? Can request fields be manipulated? Are functions restricted by role?