OWASP API Security Top 10: How to Test Every Risk (2026 Guide)

The OWASP API Security Top 10 lists the ten most critical security risks for APIs. The current edition, published in 2023, was rebuilt around the failures that keep appearing in real API breaches and penetration tests: authorization mistakes at the object, property, and function level, plus business-logic abuse. Injection, which dominated older web lists, no longer has its own category.

This article was created with AI assistance. Category definitions follow the OWASP API Security Top 10 2023 edition, which is the current API list as of October 14, 2026.

For each risk below you will find what it means, a concrete example, how to test for it, and how much of that testing a dynamic scanner can realistically automate. If you need a phase-by-phase test plan instead, use the companion API penetration testing checklist.

What is the OWASP API Security Top 10?

The Open Worldwide Application Security Project (OWASP) publishes awareness lists that rank common security risks by exploitability, prevalence, detectability, and impact. The API Security Top 10 exists because APIs fail differently from server-rendered web applications. An API exposes object identifiers, business operations, and data models directly to the client. When authorization logic is missing from even one handler, an attacker does not need a clever payload—just a different ID.

The 2023 categories are:

How the API Top 10 differs from the OWASP Top 10

The general OWASP Top 10 (latest edition: 2025) covers web applications broadly, with categories such as Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, and Injection. The API list zooms in on access control and splits it into three distinct API failure modes—object level (API1), property level (API3), and function level (API5)—because each one requires a different test.

Use both lists together. The web Top 10 is a good organization-wide baseline; the API Top 10 tells you what to test on every endpoint your clients call.

API1:2023 — Broken Object Level Authorization (BOLA)

What it is: The API authenticates the caller but does not check whether that caller is allowed to access the specific object requested. BOLA is also called IDOR (insecure direct object reference). It ranks first because it is common, easy to exploit, and often exposes other customers’ data.

Example: Alice is signed in and fetches her invoice. She changes the ID and receives Bob’s.

GET /api/v1/invoices/10482 HTTP/1.1
Authorization: Bearer <alice-token>

HTTP/1.1 200 OK
{"id":10482,"customerId":"bob-77","total":1840.00,"billingAddress":"..."}

How to test: Create two users who each own objects. For every operation that takes an object identifier—in the path, query, body, or header—replay User A’s request with User B’s identifier and compare the result. Test reads and writes: a protected GET next to an unprotected PATCH or DELETE is a common pattern. The full procedure is in our step-by-step IDOR testing guide.

Automation: High, if the scanner knows about multiple users and which objects they own. Single-identity scanners cannot detect BOLA because they never have a second user’s object to request.

Fix: Enforce ownership or tenancy in the data-access layer (for example, every query scoped by the authenticated tenant), not only in the controller.

API2:2023 — Broken Authentication

What it is: Flaws in how the API verifies identity: credential stuffing without throttling, weak password reset flows, tokens that are not validated properly, long-lived or non-expiring tokens, and sensitive operations that do not require re-authentication.

Example: The API accepts a JWT whose signature has been stripped and whose algorithm is set to none, or it accepts tokens after their exp claim has passed.

How to test:

• Send requests with no token, a malformed token, an expired token, and a token signed with a different key.
• Tamper with JWT claims (role, subject, tenant) and check whether the signature is still enforced. See how to test JWT authentication vulnerabilities.
• Attempt repeated failed logins and check for throttling, lockout, or CAPTCHA.
• Compare error messages for valid and invalid usernames to detect account enumeration.
• Try well-known default credentials on administrative or service accounts in test environments.

Automation: High for token handling, enumeration, and rate-limit gaps. Multi-step flows such as password reset and MFA enrollment usually need manual review.

API3:2023 — Broken Object Property Level Authorization

What it is: This category merges two older risks: excessive data exposure (the response includes properties the caller should not see) and mass assignment (the request can set properties the caller should not control).

Example: A user updates their profile and adds a field the UI never sends.

PATCH /api/v1/users/me HTTP/1.1
Content-Type: application/json

{"displayName":"Alice","role":"admin","emailVerified":true}

How to test: Compare each response against the minimum data the client needs, looking for internal IDs, password hashes, tokens, other users’ personal data, or internal flags. For writes, add privileged-looking properties (role, isAdmin, tenantId, price, status, ownerId) and read the object back to confirm whether they persisted. Our mass assignment testing guide covers how to do this without corrupting test data.

Automation: Medium to high. Scanners can inject candidate properties and verify persistence; deciding whether an exposed field is sensitive benefits from schema context and human review.

API4:2023 — Unrestricted Resource Consumption

What it is: The API does not limit how much work a client can make it do: request rate, page size, upload size, number of items in a batch, or calls to paid third-party services such as SMS or email.

How to test: Request ?limit=100000; upload a file far larger than the documented maximum; send a batch with thousands of items; trigger an SMS or email flow repeatedly and see whether anything stops you. Check for 429 Too Many Requests and rate-limit headers on authentication and other costly endpoints.

Automation: Medium. Scanners can detect missing rate limits and oversized-upload acceptance, but load-style tests should run only in environments built for them.

API5:2023 — Broken Function Level Authorization (BFLA)

What it is: A user can call an operation their role should not reach at all—for example, a regular user calling POST /api/admin/users or DELETE /api/v1/organizations/{id}. BOLA asks “can I access this object?”; BFLA asks “can I call this function?” We compare them in depth in BFLA vs BOLA.

How to test: Build a matrix of roles and operations from your OpenAPI spec. Call every privileged operation with every lower-privileged role and with no credentials. Also try alternate HTTP methods on the same path, since GET /users/{id} may be open while PUT /users/{id} should be admin-only.

Automation: High when the scanner knows the expected access for each role; impossible to judge without that context, because a 200 OK is correct for an admin and a vulnerability for a viewer.

API6:2023 — Unrestricted Access to Sensitive Business Flows

What it is: A flow works exactly as coded but can be abused in ways that hurt the business: scalping limited inventory, creating thousands of trial accounts, mass-redeeming referral credits, or manipulating cart and payment amounts.

How to test: Identify flows with financial or reputational impact. Try to automate them at high speed, skip steps, reorder steps, replay a completed step, and tamper with client-supplied totals, quantities, and prices.

Automation: Partial. Generic patterns—negative quantities, client-controlled totals, payment amount tampering—can be probed automatically. Organization-specific abuse cases still need a threat model.

API7:2023 — Server Side Request Forgery (SSRF)

What it is: The API fetches a URL supplied by the client—webhooks, image imports, PDF renderers, URL previews—without restricting the destination. Attackers use it to reach internal services or cloud metadata endpoints.

How to test: For every parameter that accepts a URL or hostname, supply an out-of-band callback URL you control, internal addresses, and alternate encodings of them. Observe whether the server makes the request and whether the response or timing leaks information.

Automation: Medium. Out-of-band detection works well where it is available; blind SSRF in asynchronous jobs often needs manual follow-up.

API8:2023 — Security Misconfiguration

What it is: A broad category covering permissive CORS, missing transport security, verbose stack traces, exposed debug or admin endpoints, unnecessary HTTP methods, legacy XML parsers vulnerable to XXE, and server fingerprinting headers.

How to test: Send an Origin: https://evil.example header and check whether it is reflected with credentials allowed. Trigger errors with malformed input and inspect responses for stack traces or SQL fragments. Probe for well-known debug paths, schema documents, and XML content types.

Automation: High. Misconfiguration checks are where scanners are most mature.

API9:2023 — Improper Inventory Management

What it is: You cannot protect APIs you do not know about. Old versions such as /v1 remain reachable after /v2 ships, staging hosts are exposed to the internet, and undocumented endpoints skip review.

How to test: Compare the operations in your OpenAPI spec or Postman collection with what is actually reachable. Request older version prefixes. Check whether public schema documents expose internal operations.

Automation: Partial. Spec-driven scanners test what is documented and can flag publicly exposed schemas; full discovery needs traffic analysis or gateway inventory. Keeping your spec accurate pays off twice—see how to write an OpenAPI spec that makes security testing easier.

API10:2023 — Unsafe Consumption of APIs

What it is: Your API trusts responses from third-party APIs—payment providers, enrichment services, partner integrations, webhooks—and passes that data into queries, redirects, or business decisions without validation.

How to test: Review each integration: is the transport authenticated, are redirects followed blindly, is the payload validated against a schema, and are webhook signatures verified? Send unsigned or forged webhook calls and see whether they are accepted.

Automation: Low to medium. Unsigned webhook acceptance can be probed dynamically; most of this category is design review.

What automated API DAST can cover

No single tool covers the entire list. The realistic split for a role-aware, specification-driven DAST scanner looks like this:

The pattern is clear: the highest-ranked risks are the ones generic scanners miss and role-aware scanners catch. That is why DastPilot starts every scan from your API definition plus who is allowed to call each operation. You can see how findings are reported in the sample API security report.

How to prioritize your OWASP API Top 10 program

1. Start with authorization (API1, API3, API5). These produce the largest data breaches and are the easiest for attackers to exploit at scale.
2. Lock down authentication (API2). Token validation and brute-force protection are prerequisites for everything else.
3. Automate the regression baseline. Run role-aware scans on every release candidate so a fixed BOLA stays fixed. Our guide to API security testing in CI/CD shows how to do this without slowing deployments.
4. Threat-model business flows (API6) and integrations (API10). Schedule focused manual reviews for the flows that move money or create accounts.
5. Keep your inventory honest (API9). Treat the OpenAPI spec as a security artifact and retire old versions deliberately.

Frequently asked questions

What is the latest version of the OWASP API Security Top 10?

The current OWASP API Security Top 10 is the 2023 edition. It replaced the 2019 list, merged excessive data exposure and mass assignment into Broken Object Property Level Authorization, and added Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery, and Unsafe Consumption of APIs.

What is the number one API security risk?

Broken Object Level Authorization (BOLA), also called IDOR, is API1 in the OWASP API Security Top 10. It occurs when an API returns or modifies an object without checking that the caller is allowed to access that specific object.

Can a scanner test the whole OWASP API Top 10?

Not completely. Role-aware DAST can automate most authorization, authentication, property-level, and misconfiguration testing. Business-flow abuse, unsafe third-party consumption, and shadow API discovery still need threat modeling, design review, or traffic analysis.

Is the OWASP API Top 10 a compliance standard?

No. It is an awareness document, not a certification or compliance framework. Many teams use it to scope penetration tests and to map findings for frameworks such as SOC 2, ISO 27001, and PCI DSS.

How is BOLA different from BFLA?

BOLA is about access to a specific object, such as another customer’s invoice. BFLA is about access to a function, such as a regular user calling an admin-only endpoint. Both require testing with more than one user or role.