Every OWASP API Security Top 10 (2023) risk explained with real-world examples — from BOLA and broken authentication to SSRF and unsafe API consumption. Includes the truth behind the "2025" search confusion, an FAQ section, and how autonomous DAST maps to each category.
Continue reading
If you've searched for "OWASP API Top 10 2025," you've probably noticed the results are a little inconsistent. Here's the clarification worth having up front: the OWASP API Security Top 10's current edition is still 2023 - it hasn't been revised since. What did get a 2025 refresh is the separate, general OWASP Top 10 for web applications, which is a different list covering a different (broader) scope. Some sites have started attaching "2025" to API-specific content, which understandably causes confusion. This guide covers the current, official OWASP API Security Top 10 (2023) - the list that actually governs API security programs, compliance mappings, and most DAST/API scanning tools today.
With that cleared up: APIs now carry the majority of the traffic, business logic, and sensitive data that used to sit behind traditional web application interfaces. They don't have a UI to obscure what's happening underneath, which means every authorization gap, every misconfigured endpoint, and every unvalidated input is one request away from exposure. That's exactly why OWASP maintains a dedicated list for API risks, separate from the general web application Top 10.
Below is every category in the OWASP API Security Top 10 (2023), explained with a concrete, realistic example of how each one gets exploited.
A Quick Note on 2023 vs. 2025
To be precise about what changed and when:
OWASP API Security Top 10 - last updated in 2023. This is the API-specific list and the subject of this guide. OWASP Top 10 (general/web application) - updated in 2025. It covers broader application security risks (Broken Access Control, Security Misconfiguration, Injection, etc.) and now folds SSRF into its Broken Access Control category - a change that overlaps conceptually with API7 below but applies to the general list, not the API-specific one.
If your team is building an AppSec program that spans both web applications and APIs, you'll want both lists - they're complementary, not duplicates.
The OWASP API Security Top 10 (2023), Explained API1:2023 - Broken Object Level Authorization (BOLA)
What it is: APIs frequently expose endpoints that handle object identifiers - user IDs, order IDs, account numbers - as part of the request. BOLA happens when the API fails to verify that the authenticated user actually has permission to access the specific object they're requesting, relying only on the fact that they're authenticated at all.
Real example: An e-commerce API exposes GET /api/orders/{order_id}. A logged-in user views their own order at /api/orders/58421 and notices the ID is sequential. By simply changing the number to /api/orders/58422, they can view another customer's order details - name, address, items purchased, even partial payment information - because the API checks that a valid session exists, but never checks that the session owner actually owns order 58422.
Why it's #1: BOLA is consistently the most exploited API vulnerability, in large part because it's so easy to trigger - no special tooling is required, just incrementing or guessing an identifier.
API2:2023 - Broken Authentication
What it is: Authentication mechanisms - token issuance, password reset flows, session management, credential validation - that are incorrectly implemented, allowing attackers to impersonate legitimate users.
Real example: A mobile banking API issues JWTs (JSON Web Tokens) that never expire and aren't properly validated for signature integrity on the server side. An attacker intercepts a token from an old session, and because the API doesn't check expiration or re-validate the signing key, that token continues to work indefinitely - even after the legitimate user has logged out or changed their password.
API3:2023 - Broken Object Property Level Authorization
What it is: This category merges what used to be two separate risks - Excessive Data Exposure and Mass Assignment - because they share the same root cause: the API doesn't properly validate which specific fields (properties) of an object a user should be able to read or write, even if they're authorized to access the object itself.
Real example (excessive exposure): A "get user profile" endpoint returns the entire user object from the database - including fields like internal_risk_score, is_admin, or hashed_password - because the API returns the full object rather than a filtered response, even though the frontend only displays name and email.
Real example (mass assignment): A "update profile" endpoint accepts a JSON body and maps every field directly to the database record. A user submits a request that includes "role": "admin" alongside their legitimate name change - and because the API doesn't restrict which fields can be written, the user silently grants themselves admin privileges.
API4:2023 - Unrestricted Resource Consumption
What it is: APIs that don't enforce limits on request rate, payload size, or resource-intensive operations, allowing attackers to exhaust server resources, drive up cloud costs, or perform brute-force attacks.
Real example: A "password reset" endpoint has no rate limiting. An attacker scripts thousands of requests per minute against it, either brute-forcing OTP codes or simply driving up SMS/email delivery costs for the business - a denial-of-wallet attack rather than a traditional denial-of-service.
API5:2023 - Broken Function Level Authorization (BFLA)
What it is: Where BOLA is about accessing someone else's data, BFLA is about accessing functions you shouldn't have access to at all - typically administrative or privileged operations that a lower-privileged user can still reach if the endpoint doesn't check role/permission before executing.
Real example: A SaaS platform has both /api/user/settings (regular users) and /api/admin/settings (admins only) endpoints built on the same underlying controller. Because the admin-only check was implemented on the frontend (hiding the admin UI) rather than enforced server-side, a regular user who directly calls /api/admin/settings via a tool like Postman can modify account-wide settings meant to be admin-only.
API6:2023 - Unrestricted Access to Sensitive Business Flows
What it is: A newer addition to the list (added in 2023). This risk isn't about a technical flaw in a single endpoint - it's about a legitimate business process (ticket purchasing, account creation, coupon redemption) being abused at automated scale because the API doesn't distinguish between a human user and a script.
Real example: A concert ticketing API allows any authenticated account to purchase tickets. A scalper scripts hundreds of account creations and ticket-purchase requests within seconds of tickets going on sale, buying out inventory before real customers can complete checkout - because nothing in the API flow detects or throttles this non-human purchasing pattern.
API7:2023 - Server-Side Request Forgery (SSRF)
What it is: SSRF occurs when an API fetches a remote resource based on a user-supplied URL or identifier without validating or restricting the destination, allowing an attacker to make the server issue requests to internal systems it wasn't meant to reach.
Real example: A "profile picture from URL" feature lets users submit an image URL, which the server then fetches. An attacker submits an internal cloud metadata URL (a common pattern for AWS/GCP/Azure environments) instead of an image link. The server, trusting the input, fetches that internal endpoint on the attacker's behalf - potentially returning cloud credentials or internal configuration data that should never be reachable from outside the network.
API8:2023 - Security Misconfiguration
What it is: APIs shipped with insecure default settings, unnecessary HTTP methods enabled, verbose error messages that leak stack traces, missing security headers, or overly permissive CORS policies.
Real example: A production API has debug mode left enabled, so any malformed request returns a full stack trace - including internal file paths, database connection strings, and framework version numbers - handing an attacker a detailed map of the backend for free.
API9:2023 - Improper Inventory Management
What it is: Organizations losing track of which API versions, environments, and endpoints actually exist and are exposed - old versions, staging environments, and undocumented endpoints that don't get the same security scrutiny as the current production API.
Real example: A company migrates from /api/v1/ to /api/v2/ with proper authentication and rate limiting on the new version - but never decommissions /api/v1/, which lacks the newer security controls. Attackers who discover the old version through reconnaissance can bypass the newer protections entirely by simply targeting the forgotten endpoint.
API10:2023 - Unsafe Consumption of APIs
What it is: The mirror image of the rest of the list - this risk is about how your application trusts data coming back from third-party APIs, integrations, and webhooks, often with less scrutiny than input from your own users because it's assumed to be "trusted" simply because it came from a partner system.
Real example: An application integrates with a third-party payment processor's webhook to confirm successful transactions. The application trusts the webhook payload without verifying its signature or source, so an attacker who can guess or intercept the webhook URL can send a fake "payment successful" event and unlock paid content without ever actually paying.
Why This List Keeps Getting Harder to Defend Against Manually
Three out of the top five categories are authorization failures (BOLA, Broken Object Property Level Authorization, BFLA) - and authorization bugs are notoriously difficult to catch with static analysis, because they're not really about code correctness, they're about business logic: does this specific user have the right to perform this specific action on this specific object? That question can only really be answered by testing the running application's actual behavior - which is exactly what dynamic, runtime-based testing is built for.
How Autonomous DAST Maps to the OWASP API Top 10
An Autonomous DAST & API Security Testing Platform is built to test for this exact class of risk continuously, rather than relying on point-in-time manual review:
BOLA and BFLA detection - testing authenticated requests against object and function boundaries a user shouldn't be able to reach, the way an attacker actually would Reachability-based prioritization - separating findings that are merely present in the code from ones that are genuinely exploitable in the running API, which matters enormously for a list this dominated by business-logic authorization issues rather than clean-cut code flaws REST, GraphQL, and OpenAPI coverage - testing based on the actual API specification rather than guesswork, so newer or less-documented endpoints (the API9 inventory problem) don't slip through untested Continuous, CI/CD-integrated scanning - catching misconfigurations (API8) and exposure issues before they reach production, on every build rather than during an annual audit
ThreatSpy, an Autonomous DAST & API Security Testing Platform, covers OWASP API Top 10 categories including BOLA and BFLA detection, security misconfiguration and cloud exposure checks, SSRF and injection testing, and REST/GraphQL/OpenAPI-based scanning - with exploit-backed validation to confirm which findings are genuinely reachable rather than theoretical.
Frequently Asked Questions
Is the OWASP API Security Top 10 the same as the OWASP Top 10? No. The general OWASP Top 10 covers web application security risks broadly and was last updated in 2025. The OWASP API Security Top 10 is a separate, API-specific list last updated in 2023. Organizations building APIs typically need to reference both.
What is the most common API vulnerability? Broken Object Level Authorization (BOLA) is consistently reported as the most exploited API vulnerability, accounting for a significant share of real-world API attacks, largely because it requires no special tooling to exploit - often just manipulating an ID in a request.
How often does OWASP update the API Security Top 10? There's no fixed schedule. The list was first published in 2019 and revised once, in 2023. OWASP updates it when there's enough new data and community input to justify a meaningful revision, rather than on a set annual cycle.
Can automated tools detect OWASP API Top 10 vulnerabilities? Static analysis (SAST) struggles with authorization-based risks like BOLA and BFLA because they're business-logic issues, not syntax or pattern-based code flaws. Dynamic testing (DAST) that actually exercises the running API - sending authenticated requests and checking whether object- and function-level boundaries are enforced - is generally better suited to catching this category of risk, though manual review remains valuable for the most complex business-logic flows (API6).
Does the OWASP API Top 10 apply to GraphQL APIs, not just REST? Yes. The categories are protocol-agnostic - BOLA, broken authentication, and the rest apply to GraphQL just as much as REST, though the specific exploitation technique (e.g., abusing GraphQL introspection or nested queries) can look different from a REST-based attack.
The Bottom Line
The OWASP API Security Top 10 has stayed remarkably consistent on one point since 2019: authorization, not injection, is where APIs actually break. Three of the top five risks in the 2023 edition are authorization failures, and each of the examples above shares the same root problem - an API trusting that a user is who they say they are without properly checking what they're actually allowed to do.
Manual code review and periodic audits struggle to keep pace with this category of risk, especially as API surfaces grow across REST, GraphQL, and constantly-shipping microservices. Continuous, exploit-validated testing - checking real authorization boundaries against a live, running API on every build - is the practical way to keep this list from becoming a postmortem instead of a checklist.
Want to see where your APIs stand against the OWASP API Security Top 10? Request a ThreatSpy demo and get a reachability-based breakdown of your actual exposure, not just a list of theoretical findings.
