OWASP API Security Top 10: The 2026 Guide With Examples

What Is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a standard awareness document that ranks the ten most serious security risks specific to application programming interfaces. First published in 2019 and revised in 2023, it is maintained by the OWASP API Security Project as the API-focused counterpart to the general web application list.

It exists because APIs have a different attack surface. A traditional web page couples data and presentation, so a lot of logic sits server-side and out of reach. A REST or GraphQL API strips that away: it exposes structured endpoints, predictable object identifiers, and full data objects directly to the client. The result is that the failures which matter most for APIs are not the same ones that top the web list.

Injection and cross-site scripting dominate web app testing. In API testing, the recurring finding is broken authorization: an endpoint that authenticates you correctly, then never checks whether the specific record you asked for actually belongs to you. Seven of the ten items below are, at heart, authorization problems.

The 10 API Security Risks, Explained

Here is the full OWASP API Security Top 10 for the 2023 edition, each with the failure it describes and a concrete example of how it is exploited. The IDs (API1 through API10) are the official OWASP labels and you will see them cited in pentest reports and bug bounty triage.

API1:2023 - Broken Object Level Authorization (BOLA)

The server checks that you are logged in but not that the object you requested is yours. You call GET /api/orders/1024, see your own order, then change the ID to 1025 and read someone else's. This is the same root cause as an IDOR flaw, and it is the most prevalent and damaging API vulnerability by a wide margin, tracked as CWE-639. Every endpoint that takes an ID needs a per-request check that the current user owns that specific object.

API2:2023 - Broken Authentication

The mechanism that proves who you are is implemented weakly. Common cases: login endpoints with no rate limiting that fall to credential stuffing, JWTs signed with a guessable secret or accepting the none algorithm, tokens passed in the URL where they leak into logs, and password-reset flows that do not invalidate old tokens. Once authentication breaks, every downstream authorization check is moot.

API3:2023 - Broken Object Property Level Authorization

Authorization is checked at the object level but not at the property level. This merges two older risks. In mass assignment, you add "role": "admin" to a profile-update request and the API binds it straight to the database. In excessive data exposure, a GET on your own user returns the full record, including fields like passwordHash or isVerified, with the client expected to hide them. Both come from trusting the shape of the request or response instead of filtering it server-side.

API4:2023 - Unrestricted Resource Consumption

Every API request costs CPU, memory, bandwidth, or money (think SMS and email quotas). When there is no rate limit or size cap, an attacker sends ?limit=9999999, uploads a huge payload, or hammers an expensive endpoint until the service falls over or the cloud bill explodes. This is the risk behind both denial of service and runaway third-party costs.

API5:2023 - Broken Function Level Authorization

Where BOLA is about which data you can touch, this is about which actions you can perform. A standard user discovers the admin route POST /api/admin/users or swaps a GET for a DELETE and the server executes it, because the role check lives in the UI and not the endpoint. Guessable admin paths and unguarded HTTP methods are the usual entry points.

API6:2023 - Unrestricted Access to Sensitive Business Flows

A flow works exactly as designed, but the API never considers what happens when it is automated. Scripts buy every concert ticket the second they drop, mass-create accounts to farm a signup bonus, or scrape a full product catalog. There is no single "bug" to patch here, the fix is detecting and throttling abnormal use of a legitimate feature.

API7:2023 - Server Side Request Forgery

An API fetches a remote resource from a user-supplied URL without validating it, so you point the server at internal targets like http://169.254.169.254 to lift cloud credentials. SSRF migrated onto the API list because "import from URL" and webhook features are everywhere in modern APIs. Our full SSRF attack guide covers the payloads and filter bypasses in depth.

API8:2023 - Security Misconfiguration

The API works, but the deployment leaks. Verbose stack traces in error responses, missing security headers, permissive CORS that returns Access-Control-Allow-Origin: * on authenticated endpoints, unnecessary HTTP methods left enabled, and unpatched components all sit here. None of these is a clever exploit, they are defaults nobody hardened.

API9:2023 - Improper Inventory Management

You cannot protect an endpoint you forgot exists. A team ships /api/v3/, patches it, and leaves the old /api/v1/ running with the original bug. These "zombie" and "shadow" APIs, plus exposed staging hosts and undocumented debug endpoints, are a favorite bug bounty target precisely because nobody is watching them.

API10:2023 - Unsafe Consumption of APIs

Developers validate user input carefully, then trust data from third-party APIs completely. If your service pulls from a partner API and pipes the response into a query or follows its redirects without checks, a compromise of that partner becomes a compromise of you. Treat integrated APIs as untrusted input, the same as anything a user submits.

How to Test an API Against the Top 10

How do you test an API for these risks? Start by mapping every endpoint, then attack authorization first: replay each request as a different user and with tampered object IDs. Authorization bugs (BOLA and function-level) are the highest-value findings and the easiest to miss with automated scanners, so they deserve manual attention.

A practical order of operations:

1. Enumerate the surface. Pull the Swagger or OpenAPI spec, proxy the mobile or web client through Burp, and list every route, method, and parameter. Note the ones taking IDs.
2. Test object-level authorization. Capture a request for one of your objects, then replay it with another user's ID. If you get their data back, that is BOLA (API1).
3. Test function-level authorization. Take an admin-only action captured from a privileged account and replay it with a low-privilege token. Try changing the HTTP method too.
4. Probe properties. Add unexpected fields like role or isAdmin to write requests (mass assignment) and inspect read responses for fields the UI hides (excessive data exposure).
5. Hit the limits. Remove rate limits by rotating tokens, request oversized pages, and watch for resource-consumption and business-flow abuse.

When testing real applications, the finding that pays out most often is still BOLA on a nested route. Teams protect the obvious /users/{id} endpoint, then forget the sub-resource /users/{id}/documents/{docId}, where the second ID is never checked against the first. Always test the deepest ID in the path.

How to Secure Your APIs

Defending against the OWASP API Security Top 10 comes down to a handful of controls applied consistently, not a product you bolt on. These are the ones that move the needle:

• Authorize every object, every request. On each endpoint that takes an ID, verify the authenticated user owns that exact record server-side. This single habit closes BOLA, the most common API bug.
• Enforce function-level roles at the endpoint. Put the role check in the route handler, never in the client. Deny by default, and reject unexpected HTTP methods.
• Filter properties on the way in and out. Bind only an explicit allowlist of fields on writes to stop mass assignment, and serialize only the fields a caller should see on reads.
• Rate limit and cap everything. Set request quotas, maximum page sizes, and payload limits so a single caller cannot exhaust resources or automate a sensitive flow.
• Keep an API inventory. Track every host, version, and endpoint, retire old versions, and pull staging and debug routes off the public internet.

Notice that four of the five map to authorization and input handling. Get those right and the majority of the list closes on its own.

API Security Top 10 vs the Original OWASP Top 10

The two lists overlap but are not interchangeable, and the difference is the point. The original OWASP Top 10 is written for full web applications and leads with broad categories like injection and security misconfiguration. The API list zooms into the failures that dominate API-only attack surfaces.

• Authorization is front and center. Three of the API top five are authorization failures (BOLA, function-level, property-level). On the web list these are folded into a single Broken Access Control entry.
• Injection is smaller here. Classic injection matters for APIs too, but it does not lead the way it does on the web. When it appears, our SQL injection tutorial covers the mechanics that carry straight over to API parameters.
• Business logic gets its own slot. Unrestricted access to sensitive business flows (API6) has no direct equivalent on the web list, because API automation makes it a first-class problem.

If you test web apps and APIs, learn both lists. The web list frames the categories of risk; the API list tells you where to actually spend your time on a modern JSON backend.

Legal and Ethical Considerations

• Test only APIs you own, dedicated practice labs, or targets inside an authorized engagement or a bug bounty program's defined scope.
• BOLA testing exposes real user data. If you confirm the flaw, stop at proof of impact and never download, keep, or share other people's records.
• Rate-limit and resource-consumption testing can take a service down. Coordinate with the owner and stay within agreed limits.
• Practice destructive and business-logic techniques on intentionally vulnerable APIs, not on production systems.