OWASP API Security Top 10
A reference for the OWASP API Security Top 10 (2023) — broken object-level authorization (BOLA), mass assignment, resource exhaustion and more, with what to look for and how to fix it.
The OWASP API Security Top 10 (2023) — the flaws attackers actually hit in APIs. The numbered items are the priority order for remediation.
API1 Broken Object Level Authorization (BOLA)
Why it hurts: The most common API flaw. An endpoint fetches an object by an ID the caller supplies (e.g. /users/42) without checking the caller owns it.
Fix: Verify the requesting user’s access to the specific object on every request. Never trust client-supplied IDs; use opaque, non-guessable references.
API2 Broken Authentication
Why it hurts: Weak login flows, exposed tokens, missing lockout and rate limits — attackers reuse stolen credentials or brute-force the login.
Fix: Standard, tested auth (OAuth2/OpenID Connect), short-lived tokens with rotation, MFA, account lockout, and monitoring for credential stuffing.
API3 Broken Object Property Level Authorization
Why it hurts: Mass assignment and data exposure — clients read or write object properties they shouldn’t, like setting isAdmin or reading password hashes.
Fix: Return only the properties the caller may see, and only accept the properties the caller may set. Never bind a request body straight to a model.
API4 Resource Consumption
Why it hurts: No rate limits or quotas on expensive endpoints — a few requests can exhaust CPU, memory or disk, or balloon your cloud bill.
Fix: Rate limiting and quotas per user/IP, size limits on requests, caches for expensive queries, timeouts on third-party calls, and scalable design.
API5 Broken Function Level Authorization
Why it hurts: Admin or privileged endpoints check nothing. Any authenticated user can call them by guessing the route.
Fix: Enforce authorization on every function, deny-by-default, and test per-role access. Keep default roles least-privilege.
API6 Unrestricted Access to Sensitive Business Flows
Why it hurts: Valuable flows — bulk ordering, discount abuse, mass account creation, scraping — have no guardrails and get gamed.
Fix: Detect automated abuse: rate limits, human/machine detection, device fingerprinting, and business-logic monitoring on high-value flows.
API7 Server-Side Request Forgery
Why it hurts: An endpoint accepts a URL and fetches it server-side, letting an attacker probe internal networks and cloud metadata.
Fix: Allowlist destinations, block private and link-local address space, disable redirects, and authenticate all outbound requests.
API8 Security Misconfiguration
Why it hurts: Open CORS, verbose error messages leaking internals, unhardened servers, missing TLS, default accounts.
Fix: Automated config scans, minimal CORS, generic error messages, hardening guides, and disabling unused endpoints.
API9 Improper Inventory Management
Why it hurts: Old API versions, shadow endpoints and debug routes still reachable — attacked because they’re forgotten and unpatched.
Fix: Inventory all API hosts and versions, deprecate and shut down old versions, and keep documentation current.
API10 Unsafe Consumption of APIs
Why it hurts: Your app trusts data from third-party APIs and integrates with them naively — poisoned responses become your vulnerability.
Fix: Validate and sanitize third-party data, verify integrity (TLS + signatures), know your suppliers’ security posture, and isolate their data from yours.
Source: OWASP Foundation — owasp.org/API-Security
How to use this reference
This is a reference to the OWASP API Security Top 10 (2023). Review each risk against your APIs — especially authorization and rate limits — and use it to prioritise fixes.
FAQ
How is the API Top 10 different from the web Top 10?
It focuses on flaws specific to APIs — object-level authorization, mass assignment, resource exhaustion and improper inventory — though there is overlap with the general web list.
What is BOLA?
Broken Object Level Authorization (API1) is the top API flaw: an endpoint returns or modifies an object by an ID the caller supplies (e.g. /users/42) without checking the caller owns it.
How do I fix most of these?
Enforce authorization on every object and function, never trust client-supplied IDs, add rate limits and size limits, keep an inventory of API versions, and validate all third-party data. Most items are about defaulting to deny.
Is following this list enough?
It’s a strong baseline but not a complete standard. Pair it with your own threat modeling, automated scanning and review against newer guidance.