OWASP API Security Top 10: Full Guide & Mitigations

A request for GET /accounts/1043/statements carries a valid token and a well-formed path. Nothing in it would trip a signature filter. If account 1043 belongs to a different customer, the API has still leaked data without a single malformed byte. That scenario is the first entry in the OWASP API Security Top 10. Much of the rest of the list is a variation on the same theme: the caller is authenticated, the request is valid, and the API still does something it shouldn't.

This guide covers all ten risks in the 2023 edition, with an attack example and a mitigation for each. It also covers what changed from 2019 and where each mitigation belongs. Some controls belong in a spec review before an API ships. Others only work as authorization and traffic controls at runtime. If you're building a broader API governance program around these risks, that split decides which team owns which control.

At a glance:

• The 2023 edition is still the current OWASP API Security Top 10. OWASP has not published a 2025 or 2026 API edition.
• Four of the first five risks (API1, API2, API3 and API5) are identity and access failures.
• The WSO2 OWASP ruleset covered later in this guide maps its checks to five categories. Passing those checks doesn't eliminate those risks, and every category still benefits from design review, targeted static analysis and runtime testing.
• A spec that passes every OWASP lint rule can still ship with a BOLA bug.

(Last verified: October 5, 2026)

What Is the OWASP API Security Top 10?​

The OWASP API Security Top 10 is an awareness document that ranks the ten most critical security risks specific to APIs. It is published by OWASP, the Open Worldwide Application Security Project (formerly the Open Web Application Security Project). It is separate from the general OWASP Top 10 for web applications. The current edition is 2023.

The two lists share themes but differ in focus. The web application list covers risks across the whole application stack. The API list concentrates on how APIs fail in particular: endpoints that take object IDs from the client, business flows exposed to scripts, and integrations with other APIs. OWASP states that the API list does not replace the other Top 10 lists. A team that ships both web pages and APIs needs both.

Is There a Newer OWASP API Top 10? What Changed Since 2019​

The 2023 edition is still the current OWASP API Security Top 10 as of October 2026. The project's source repository holds only two editions, 2019 and 2023.

The general OWASP Top 10:2025 is a different list. It covers web applications, and its categories, such as Software Supply Chain Failures, follow a different taxonomy from the API list. If you've seen "OWASP Top 10 2025" in a requirement, check which list it means before you map controls to it.

The 2023 update arrived four years after the first edition. These are the entries that changed:

Injection didn't stop mattering when it lost its own slot. It now appears inside other categories. The 2023 API8 scenario is a logging library that resolves a JNDI lookup taken from a request header. The API10 scenario is an SQL injection payload that arrives through a third-party service. The vulnerability class is unchanged, and the 2023 list files it under the weakness that let it in.

The OWASP API Security Top 10 (2023 Edition), Risk by Risk​

Authorization failures dominate the top of the list. API1, API3 and API5 are authorization at three levels of granularity: the object, the property and the function. API2 is the authentication layer underneath them. None of the four can be fixed by a filter that only sees request syntax, which makes them the place to start when review time is short.

OWASP API Security Top 10 (2023) at a glance. "Partly" means the WSO2 ruleset flags some gaps in the OpenAPI definition, and runtime controls are still required.

API1:2023 Broken Object Level Authorization (BOLA)​

Broken object level authorization happens when an endpoint takes an object ID from the client and acts on it without checking that the caller may access that object. The classic attack swaps one ID for another, such as /orders/1043 for /orders/1044. In OWASP's example, an attacker scripts a list of shop names into /shops/{shopName}/revenue_data.json and reads sales data for thousands of stores.

The fix is an authorization check on the server, in every function that reads or writes a record using client input. Authorize the caller for the requested action on that specific object, using ownership, role, delegation, tenant and any other applicable policy context. OWASP is explicit that comparing the user ID in the JWT with an ID parameter covers only a small subset of cases. Random identifiers such as UUIDs make enumeration slower. They don't replace the check, because an ID exposed by another endpoint or a log can be replayed like any other. Write authorization tests and don't deploy changes that fail them.

API2:2023 Broken Authentication​

Broken authentication covers any flaw that lets an attacker assume another identity. OWASP's list of symptoms is concrete. It includes permitting credential stuffing, sending tokens in URLs, accepting unsigned JWTs with {"alg":"none"} and ignoring the expiry claim. One scenario shows a login endpoint limited to three requests a minute. The attacker bypasses the limit by batching many login mutations into a single GraphQL request.

Use standard protocols instead of custom schemes. OWASP notes that OAuth is not authentication, and neither are API keys. OpenID Connect adds the identity layer on top of OAuth 2.0. Validate the signature, issuer, audience and expiry of every JWT, and restrict accepted algorithms as RFC 8725 recommends. Treat password recovery endpoints as login endpoints, with anti-brute-force limits stricter than the rest of the API. Require re-authentication for sensitive changes such as the account email, and use multi-factor authentication where possible.

API3:2023 Broken Object Property Level Authorization (BOPLA)​

Broken object property level authorization is the 2023 merger of excessive data exposure and mass assignment. Both are failures to authorize individual fields on an object the caller is otherwise allowed to see. On the read side, an endpoint returns the whole object and relies on the client to hide sensitive fields. On the write side, the API binds whatever JSON arrives to its data model.

OWASP's booking example shows the write case. A host approves a reservation with {"approved": true}, then replays the request with an extra "total_stay_price": "$1,000,000". The API accepts the field because nothing checks whether a host may set it. A PATCH /users/me that accepts "role": "admin" is the same BOPLA bug in a different domain.

Return explicit field sets instead of serializing whole objects with generic methods like to_json(). Allowlist writable properties per role and reject everything else. Schema-based response validation adds a useful extra layer, as long as the schema itself is strict.

API4:2023 Unrestricted Resource Consumption​

Unrestricted resource consumption covers anything an attacker can exhaust: CPU, memory, bandwidth, storage or a paid third-party service. In OWASP's SMS example, a script calls a password reset endpoint tens of thousands of times. Each call triggers an SMS from a provider charging $0.05 per message, and the company loses thousands of dollars in minutes.

Rate limiting is part of the answer, not all of it. Cap payload sizes, string lengths, array sizes and records per page, and enforce those caps on the server. Limit how many operations a single request can carry, since GraphQL batching defeats per-request limits. Throttle expensive operations harder than cheap ones. Set spending limits with every metered provider, or billing alerts where limits aren't offered.

API5:2023 Broken Function Level Authorization (BFLA)​

Broken function level authorization is a user reaching a function meant for another role. BOLA is the wrong object through a function you may use. BFLA is a function you shouldn't reach at all. In OWASP's example, a registration flow calls GET /api/invites/{invite_guid}. The attacker switches to POST /api/invites/new, an admin-only endpoint with no function-level check, and issues an invite with the admin role.

OWASP warns against judging an endpoint as administrative from its path alone. Admin functions often sit beside regular ones under paths like /api/users. Enforce access through one consistent authorization module that denies by default and grants access explicitly per role and per function. Hiding a button in the client is not a control. Coarse role checks can run at the gateway as required scopes per operation. Rules that depend on the record or business context still belong in the service.

API6:2023 Unrestricted Access to Sensitive Business Flows​

Unrestricted access to sensitive business flows is new in 2023, and it often involves no bug at all. The API works as designed. The harm comes from running a legitimate flow at machine speed. Examples include buying the stock of a limited product for resale, reserving every slot, or scripting sign-ups to farm referral credit.

Mitigation starts with a business decision. Identify which flows would hurt the business if automated. The answer varies: scripted posting is spam on one social network and an approved integration on another. Then choose controls. OWASP lists device fingerprinting, human detection such as captcha, detection of non-human timing, and blocking known proxies and Tor exit nodes. Limits keyed to the account rather than the IP address also raise the cost of attacks distributed across many addresses.

API7:2023 Server Side Request Forgery (SSRF)​

Server side request forgery happens when an API fetches a client-supplied URL without validating it. Webhooks, URL previews, file imports and custom SSO all invite it. In OWASP's webhook example, the attacker registers http://169.254.169.254/latest/meta-data/iam/security-credentials/... as a webhook target. The backend sends a test request, shows the response, and exposes cloud credentials from the instance metadata service.

OWASP notes that SSRF can't always be eliminated, so reduce it in layers. Isolate the fetching component in its own network segment. Allowlist the origins, URL schemes, ports and media types each feature needs. Disable redirects, use one well-maintained URL parser, and never return raw upstream responses to the caller. On AWS, requiring IMDSv2 adds session-oriented requests to metadata access. An inbound gateway can check a submitted URL against an allowlist. It can't confirm where that URL resolves or what the fetcher does next, so the outbound controls belong in the service and its network.

API8:2023 Security Misconfiguration​

Security misconfiguration is the broadest category. It includes missing TLS, missing or permissive CORS policies, stack traces in error messages, unnecessary HTTP verbs, missing cache-control headers and unpatched components. OWASP's two scenarios show the range. One is the JNDI logging lookup described earlier. The other is a direct-message API that omits Cache-Control, so private conversations end up in the browser cache.

Treat configuration as something you test continuously. Build a repeatable hardening baseline, review configuration across the whole stack, and run automated checks in every environment. Use TLS on every hop, internal ones included. Allow only the HTTP verbs each API needs. Give browser-facing APIs a CORS policy that names specific origins. Define error response schemas, and keep stack traces and secrets out of the messages your error handlers write. A schema-valid error string can still carry a trace.

API9:2023 Improper Inventory Management​

Improper inventory management is what happens when nobody can say which environment a host runs in, who should reach it and which version it serves. In OWASP's scenario, a beta host runs the same password reset endpoint as production, but without the rate limiter. A researcher brute-forces the six-digit reset token and can reset any user's password. OWASP also counts uninventoried data flows to third parties as a blindspot.

Inventory every host with its environment, audience and version, and generate documentation from the spec in CI so it stays current. Give each version a retirement plan. When a new version fixes a security issue, decide explicitly whether to backport the fix or retire the old version. Protect every exposed version, not only the current production release.

API10:2023 Unsafe Consumption of APIs​

Unsafe consumption of APIs reverses the usual trust direction. Developers tend to validate user input carefully but trust what well-known third-party APIs return. OWASP added this category because attackers now target a company's integrated services instead of its own APIs. In one example, an address enrichment service returns a stored SQL injection payload that the API writes into its database. In another, a compromised provider answers with 308 Permanent Redirect, and the API resends sensitive health data to the attacker's server.

Treat every upstream response as untrusted input. Validate its structure against an expected schema, then check its values for the context where they'll be used. Use parameterized queries when upstream data reaches a database, and encode it for any other interpreter it reaches. Use TLS for every integration, set timeouts, cap the resources spent processing responses, and follow redirects only to an allowlist of known locations. The same reasoning applies when the upstream is an LLM provider. Model output is third-party data, and your code should validate it before acting on it.

Design-Time vs. Runtime: Where Each OWASP Mitigation Actually Lives​

Every mitigation above lives somewhere specific. Some can be checked in an OpenAPI definition before anyone writes a handler. Others exist only in running code and live traffic. Sorting the list this way shows what a governance linter can enforce and what it structurally can't.

Five categories leave a trace in the API contract:

The right-hand column is the important one. A spec can declare a 429 response for an endpoint with no rate limit behind it. Linting shows the contract is complete, not that the implementation honors it.

This ruleset has no checks for the other five categories. Design review and static analysis still help with them, for example by catching an admin operation with no required scope or a free-form URL parameter. Their core controls depend on runtime context:

• API1 and API5 need a decision against real data, roles and policy context. Whether user 812 may act on order 1044, or whether an officer may call DELETE /users/{id}, is answered at request time.
• API6 needs behavioral context, such as how fast, from which devices and in what order a flow is being used.
• API7 and API10 concern outbound calls your service makes. They need egress allowlists and response validation in the service and its network. Inbound filtering alone can't provide them.

Linting against this ruleset covers part of five categories, and no category is fully covered by one technique. Each needs some mix of design review, static analysis, runtime testing, and gateway, identity and application controls. The guide to layered API security architecture maps which layer owns each of those controls.

How WSO2 Helps You Enforce the OWASP API Top 10​

The WSO2 API Platform covers both halves of the split, with design-time governance and runtime gateway policies managed from the same control plane. It doesn't remove the need for application code on every risk, and this section says where that code still matters.

Design-time checks in the IDE: The API Designer extension for VS Code runs an OWASP API Security Top 10 report alongside its REST design and AI readiness reports. It applies Spectral rules to the OpenAPI definition while it's being written, before it reaches a pull request. In the API Designer source (v0.9.2), the bundled OWASP ruleset contains 15 rules mapped to five categories. That count comes from the ruleset file as last changed on April 30, 2026, and it can change between releases:

A server entry and security scheme that satisfy the API2, API8 and API9 rules look like this:

servers:
  - url: https://api.example.com/v1
    description: production
    x-internal: false
components:
  securitySchemes:
    JWTBearer:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: JWS bearer token. Validation conforms to RFC8725.

Note what jwt-best-practices actually checks. It confirms that the description states RFC 8725 conformance. It verifies the declaration, not the token handling, and the runtime half has to close that gap. Teams can also point the extension at their own ruleset folder to override or extend these rules, keeping the owasp:apiN:2023-<description> naming.

Design-time checks across the organization​

In the API Platform Console, governance rulesets are Spectral YAML definitions grouped into policies. The default ruleset catalog includes an OWASP Top 10 ruleset alongside WSO2's design and style guidelines. A policy applies to all existing and new API proxies in the organization. It is evaluated when an API proxy is updated, and violations surface as notifications in the Compliance dashboard at organization, project and component level. Today the enforcement action is notification, so treat the dashboard as a review queue rather than a deployment gate.

Runtime checks at the gateway​

The runtime half runs as policies from the Policy Hub. You attach them per API or per operation, and the control plane synchronizes them to cloud or self-hosted gateways.

• API2: The JWT Auth policy verifies a token's signature, expiry, issuer, audience, scopes and required claims. In JWT Auth policy v1.3.1, the accepted signing algorithms are a fixed allowlist of RS256, PS256 and ES256, so tokens signed with none or an HMAC algorithm are rejected. Check the policy definition for the version you deploy. User authentication itself, including multi-factor and conditional login flows, comes from an identity provider such as Asgardeo.
• API4 and API6: The Basic and Advanced Rate Limit policies cap requests per time window. The advanced policy can key quotas on JWT claims, so a limit follows the account instead of the IP address.
• API5: Required scopes per operation enforce coarse function-level access. The RBAC tutorial walks through a scenario where an HR officer role can list users but can't create or delete them.
• API8: The CORS policy handles preflight requests and sets the allowed origins, headers and methods.
• API3: The JSON Schema Guardrail can validate request or response payloads against a schema, which adds the response-validation layer OWASP recommends.

Some controls stay in your services: the object-level authorization check for API1, field-level rules for API3, business-flow detection for API6, and egress controls for API7 and API10. The gateway's Backend JWT policy can generate a signed JWT carrying the authenticated user's claims and send it to the backend in a header (x-jwt-assertion by default). The header isn't proof of identity on its own. The backend should verify the signature with the gateway's public key, reject unsigned tokens, check the issuer, audience and expiry, and accept the header only on traffic that came through the gateway. That gives the service a trustworthy input for its authorization decision.

Outbound calls to LLM providers follow a separate path from this inbound API traffic, not an extra hop in front of it. The AI Gateway, managed from the same control plane, governs LLM and MCP traffic. Its guardrails, such as PII masking and JSON Schema validation, apply the API10 principle to model input and output. Schema validation checks structure only. It doesn't establish that output is true, authorized or safe to act on, so applications still validate it in context.

Conclusion​

The OWASP API Security Top 10 splits along a practical line. About half of it shows up in the API contract, where a linter can flag gaps before code ships. The rest lives in authorization decisions, traffic behavior and outbound calls, where only runtime controls help. A program built on one half leaves the other half open.

Start with the four identity and access categories at the top of the list. Then add the OWASP ruleset to design review and attach matching runtime policies at the gateway. To run both halves from one control plane, explore the WSO2 API Platform.

Frequently Asked Questions​

What is the OWASP Top 10 list?​

It is OWASP's ranked list of the most critical web application security risks. Its current edition is the OWASP Top 10:2025. The API Security Top 10 is a separate, API-specific list whose current edition is 2023.

What is OWASP API?​

The term usually refers to the OWASP API Security Project, which publishes the API Security Top 10 and related guidance for people who build, test and defend APIs.

Is OWASP Top 10 a legal requirement?​

No. OWASP publishes its Top 10 lists as awareness documents, and they carry no legal force on their own. They become binding only when a contract, regulation or internal policy adopts them.

Is OWASP free?​

Yes. The OWASP API Security Top 10 is free to use under the Creative Commons Attribution-ShareAlike 4.0 license.

Can a spec linter cover the whole OWASP API Top 10?​

No. A linter can flag contract gaps in five categories. Authorization, business-flow abuse and outbound request risks need runtime controls and application code.