OWASP API Security Top 10 (2023)
The OWASP API Security Top 10 targets risks unique to APIs, especially broken authorization that leads to mass data exposure. It gives teams a prioritized list to test and harden every endpoint they build or migrate.
Best Practice: OWASP API Security Top 10 (2023)
The OWASP API Security Top 10 is a focused list of the most critical security risks specific to application programming interfaces (APIs). Unlike the general OWASP Top 10, it targets problems unique to APIs, such as broken object-level authorization, broken authentication, and unrestricted resource consumption. It matters because modern systems expose far more logic through APIs than through traditional web pages, and authorization flaws here often lead directly to mass data exposure. For a developer it is a focused checklist of the failures that most often expose API data; for an executive it explains why API sprawl is a direct business risk. The list complements, rather than replaces, the general OWASP Top 10, which still applies to API back ends. The single most important entry is broken object-level authorization, often shortened to BOLA, because it appears in a large share of real API breaches and is easy to introduce: a developer checks that the caller is logged in but forgets to check that the caller actually owns the specific record being requested.
Step-by-Step Implementation Guidance
- Inventory every API endpoint, including internal, partner, and deprecated ones.
- Enforce object-level authorization checks on every request, not just at login.
- Validate that authenticated users can only access the specific resources they own.
- Apply strong authentication and short-lived tokens to all endpoints.
- Add rate limiting and payload size limits to prevent resource exhaustion.
- Validate and constrain all input and output schemas explicitly.
- Test endpoints against each API Top 10 category in CI and during reviews.
Common Mistakes Teams Make When Ignoring This Practice
- Checking that a user is logged in but not that they own the requested record.
- Trusting object IDs supplied by the client without an ownership check.
- Leaving old or undocumented "shadow" API versions exposed.
- Omitting rate limits, allowing scraping and denial-of-service.
- Returning more fields than the client needs, leaking sensitive data.
- Assuming a web application firewall alone stops authorization flaws it cannot see inside the request.
Tools and Techniques That Support This Practice
- OWASP ZAP and Burp Suite for API endpoint testing.
- API gateways (Kong, Apigee, AWS API Gateway) for authentication and rate limiting.
- OpenAPI/Swagger schemas to define and validate request and response contracts.
- Schema validators and fuzzers to catch input handling flaws.
- Static analysis tools mapped to authorization and data exposure risks.
- API discovery tools that surface undocumented or forgotten endpoints before attackers find them.
How This Practice Applies to Different Migration Types
- Cloud Migration: Re-check authorization and rate limiting once APIs move behind new gateways and load balancers.
- Database Migration: Verify that new data access paths still enforce per-object authorization.
- SaaS Migration: Review a vendor's API security posture and token handling before integrating.
- Codebase Migration: Re-test rewritten endpoints against every API Top 10 category to confirm controls were preserved.
Checklist
- Built a complete inventory of API endpoints
- Enforced object-level authorization on every request
- Applied strong authentication and short-lived tokens
- Added rate limits and payload size limits
- Validated input and output schemas
- Removed or secured deprecated API versions
- Added API Top 10 tests to CI