What is the OWASP API Security Top 10?

Definition

The OWASP API Security Top 10 is a dedicated security risk list for APIs — REST, GraphQL, gRPC, SOAP, and other web API architectures. Published by OWASP (Open Web Application Security Project), it was first released in 2019 and updated in 2023 to reflect the evolving API threat landscape. It addresses attack surfaces and vulnerability patterns that are specific to APIs and not fully captured by the original OWASP Web Application Top 10.

As modern applications have become API-first, the attack surface has shifted. Mobile apps, SPAs, microservices, and third-party integrations all communicate through APIs that have unique security characteristics compared to traditional web applications.

The 2023 OWASP API Security Top 10

1. API1 — Broken Object Level Authorization (BOLA): APIs fail to validate that the requesting user is authorized to access a specific object. The most prevalent API vulnerability — essentially IDOR at scale across API endpoints.
2. API2 — Broken Authentication: Weak authentication mechanisms, missing token validation, insecure credential storage.
3. API3 — Broken Object Property Level Authorization: Exposing or allowing modification of object properties the user should not have access to (mass assignment, excessive data exposure).
4. API4 — Unrestricted Resource Consumption: Missing rate limits, absent pagination controls, no request size limits — enabling DoS through resource exhaustion.
5. API5 — Broken Function Level Authorization: API functions that require elevated privileges are accessible to lower-privilege users.
6. API6 — Unrestricted Access to Sensitive Business Flows: Business workflows (checkout, account creation, bulk data export) with no controls against automated abuse.
7. API7 — Server-Side Request Forgery (SSRF): API endpoints that fetch external resources at user-supplied URLs.
8. API8 — Security Misconfiguration: Missing headers, verbose error responses, unnecessary HTTP methods, CORS misconfiguration.
9. API9 — Improper Inventory Management: Outdated API versions, undocumented endpoints, shadow APIs left in production.
10. API10 — Unsafe Consumption of APIs: Third-party API responses treated as trusted and used without validation.

Why APIs Need Their Own Top 10

APIs introduce security patterns not present in traditional server-rendered web applications:

• Objects are directly referenced by ID in API paths (/api/orders/12345) without the server-side rendering that obscures direct references in traditional apps
• API responses often return full objects, exposing fields the client should not see (excessive data exposure)
• GraphQL and REST APIs may expose more functionality than intended — field-level authorization is complex
• API versioning creates shadow APIs (v1 still running after v2 deployment) that are not maintained
• Microservice architectures create internal APIs with weaker security assumptions than external-facing APIs

BOLA: The Most Critical API Vulnerability

Broken Object Level Authorization (API1) deserves special attention. It is estimated to be present in the majority of APIs and is the root cause of most API data breaches. The pattern:

• An API endpoint accepts an object identifier: GET /api/invoices/4521
• The server returns the invoice if the user is authenticated
• The server does not verify that the authenticated user owns invoice 4521
• An attacker authenticated as any user enumerates all invoice IDs to access all invoices

Fixing BOLA requires adding object-level ownership checks to every endpoint that accepts an identifier — verifying that the authenticated principal owns or has permission to access the specific object requested.

API Security Top 10 vs. Web Application Top 10

The OWASP API Security Top 10 and Autonomous Code Governance

Hydra extends its detection coverage to API-specific vulnerability patterns. For BOLA, Hydra analyzes route definitions and controller logic to identify API endpoints that accept object identifiers without ownership verification — a code-level detectable pattern. For excessive data exposure, Hydra compares API response serializers against authorization logic to identify fields returned to callers who should not see them. CORS misconfiguration, missing rate limiting, and verbose error responses in API handlers are detected and remediated as part of Hydra's API security coverage.