The OWASP API Security Top 10 (2023): A Practical Guide

The OWASP API Security Top 10 lists the most common serious weaknesses in APIs. The 2023 edition is the current published version at the time of writing. This guide explains each item with an example and the defense that matters most.

API1: Broken Object Level Authorization (BOLA)

The API accepts an object ID and returns the object without checking the caller may access it. Changing /orders/1001 to /orders/1002 exposes another customer's order. Defense: check ownership or permission for every object on every request, centrally if possible. Random IDs help but are not a control.

API2: Broken Authentication

Weak login, token and password-reset flows: no rate limiting on login, tokens that never expire, JWTs accepted with alg: none, or secrets in URLs. Defense: use proven identity providers and libraries, short-lived tokens, rate limits and lockouts, and validate token signature, issuer, audience and expiry.

API3: Broken Object Property Level Authorization

Two flaws combined: returning properties the caller should not see (excessive data exposure) and accepting properties the caller should not set (mass assignment, such as sending "isAdmin": true). Defense: use explicit response schemas and allowlists for writable fields; never bind request bodies directly to database models.

API4: Unrestricted Resource Consumption

No limits on request rate, payload size, pagination size or expensive operations, leading to outages or large cloud bills. Defense: rate limits and quotas per client, maximum page sizes and body sizes, timeouts, and cost controls on any paid downstream calls such as LLM or SMS providers.

API5: Broken Function Level Authorization

Users can call administrative or privileged endpoints because only the UI hides them. Defense: deny by default; require explicit role checks on every function; test every endpoint with every role.

API6: Unrestricted Access to Sensitive Business Flows

Legitimate flows, such as ticket purchase, signup or coupon redemption, can be automated at harmful scale. Defense: identify the flows with business value, then add bot detection, per-account limits and anomaly monitoring. See Business Logic Vulnerabilities.

API7: Server Side Request Forgery (SSRF)

The API fetches a URL supplied by the user, letting an attacker reach internal services or cloud metadata endpoints. Defense: allowlist destinations, block private and link-local address ranges, disable redirects, and use cloud features that require session tokens for metadata access.

API8: Security Misconfiguration

Missing security headers, permissive CORS, verbose errors, default credentials, unpatched components, unnecessary HTTP methods. Defense: hardened baseline configuration as code, automated configuration checks in CI, and consistent environments.

API9: Improper Inventory Management

Old API versions, forgotten debug endpoints and undocumented "shadow" APIs remain reachable and unmaintained. Defense: keep an inventory of hosts, versions and endpoints; retire old versions; scan your own domains; require every endpoint to appear in an API specification.

API10: Unsafe Consumption of APIs

Developers trust data from third-party APIs more than user input, so a compromised partner can inject malicious content. Defense: validate and sanitize third-party responses, enforce TLS, set timeouts, limit redirects and treat integrations as untrusted.

If you can only do five things

1. Enforce object-level authorization centrally (API1, API5).
2. Use a standard authentication solution with short-lived tokens (API2).
3. Define response and request schemas with allowlists (API3).
4. Add rate limits and size limits everywhere (API4, API6).
5. Maintain an API inventory and specification (API9), then lint it in CI.

Testing

Write authorization tests as a matrix: each role against each endpoint, expecting allowed or denied. Add tests that use one user's token against another user's object IDs. These two test types find the largest share of serious API flaws.