OWASP API Security Top 10 Explained for Beginners

Mobile apps, single-page websites and partner systems all talk to servers through APIs. The page you see is only the front; the data and the rules live behind the API. OWASP publishes a separate Top 10 for APIs because their weaknesses differ from those of classic web pages. This guide follows the 2023 edition, the current one in October 2026.

API1Broken Object-Level Authorization (BOLA)

The API returns an object, such as an order or a profile, without checking that it belongs to the person asking. Changing /orders/1041 to /orders/1042 shows someone else's order. It is the most common serious API flaw. Fix: check ownership on the server for every object, on every request.

API2Broken Authentication

Weak login and token handling: no limit on password or one-time-code guesses, tokens that never expire, or JSON Web Tokens (JWTs) whose signature is not properly checked. Fix: use a well-tested authentication library, rate-limit login endpoints and verify every token fully.

API3Broken Object Property-Level Authorization

The user may see the object, but not every field in it. An API that returns a user's internal notes or password reset token alongside their name leaks data. An API that lets a user send "role": "admin" in a profile update, and accepts it, allows mass assignment. Fix: return only the fields each role needs, and accept only the fields each role may change.

API4Unrestricted Resource Consumption

No limits on how often, how much or how large. An attacker asks for a million records in one call, uploads huge files or triggers paid SMS messages in a loop. Fix: rate limits, page-size limits, timeouts and spending caps on paid third-party services.

API5Broken Function-Level Authorization

An ordinary user can call an administrator function, often just by guessing its address, such as /api/admin/users, or by changing GET to DELETE. Fix: deny by default and check the caller's role for every function, not only in the user interface.

API6Unrestricted Access to Sensitive Business Flows

Each request is valid, but automating it hurts the business: buying up limited stock with bots, creating thousands of referral accounts or reserving every appointment slot. Fix: identify the flows that matter, then add limits, device checks or human verification where they are abused.

API7Server-Side Request Forgery (SSRF)

The API fetches a URL the user supplies, such as a profile picture link or a webhook address, and an attacker points it at internal systems or cloud metadata services. Fix: allow only expected destinations and block internal addresses.

API8Security Misconfiguration

Missing security headers, permissive cross-origin (CORS) settings, verbose error messages with stack traces, or debug features left on in production. Fix: a hardened, repeatable configuration that is reviewed before each release.

API9Improper Inventory Management

Old API versions, test environments and undocumented endpoints stay online, often without the fixes the current version has. Attackers find /v1/ still running beside /v3/. Fix: keep an inventory of every API, version and environment, and retire what is no longer used.

API10Unsafe Consumption of APIs

Developers trust data from third-party APIs more than user input, so they validate it less. If the partner is compromised, or returns something unexpected, the flaw passes straight through. Fix: validate and limit data from other APIs just as you would data from users.

How Testers Approach an API

A good API test starts with a map, not a scanner. Testers collect every endpoint from the documentation, the OpenAPI file and the traffic of the real application, then build a matrix of which role should be able to call which endpoint on which object. Most serious findings, especially API1, API3 and API5, come from working through that matrix with two or more test accounts in Burp Suite. GraphQL APIs need extra care, because one endpoint can expose the whole data model. Our guides to JWT security, IDOR, SSRF and GraphQL testing go deeper.