The OWASP API Security Top 10 (2023) lists the risks specific to APIs, where authorisation flaws dominate rather than injection. In order: API1 BOLA (object-level authorisation — the #1 risk), API2 Broken Authentication, API3 Broken Object Property Level Authorization (mass assignment + excessive data exposure), API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API7 SSRF, API8 Security Misconfiguration, API9 Improper Inventory Management, API10 Unsafe Consumption of APIs. The through-line: these are logic and authorisation flaws only human-led testing reliably finds — a scanner can't know who should access what. Each explained below; for scoped delivery see API penetration testing.
// 01 Why APIs need their own Top 10
The general OWASP Top 10 describes web application risk broadly. But modern software is API-driven — mobile apps, single-page frontends and service-to-service calls all run on APIs — and APIs fail differently. The dominant risk isn't injection; it's authorisation. An API endpoint takes a request, and the question that decides everything is: did the code check that this caller is allowed this object, this field, this function? When it doesn't, the API cheerfully returns other people's data. That's why OWASP maintains a separate API Security Top 10, and why its top entries are all flavours of broken authorisation. It reflects where API breaches actually come from — not theory.
// 02 API1, API3, API5 — the authorisation trio
BOLA
Broken Object Level Authorization — change an ID in the request, read another user's record. The #1 API risk.
Object Property Auth
Reading fields you shouldn't (excessive data exposure) or writing fields you shouldn't (mass assignment).
Function-Level Auth
Calling admin or privileged endpoints as an ordinary user — the function isn't guarded.
BOLA (API1) is number one for good reason: it's ubiquitous, trivial to exploit, and leads straight to mass data exposure — one manipulated identifier walks through every record. We cover the REST-API case scanners miss in BOLA that scanners miss. The reason all three evade automation is the same: only your application knows who should access what, so a tool with no concept of your permission model can't judge whether a returned object was authorised.
// 03 API2, API4, API6 — auth, limits & business flows
API2 Broken Authentication covers weaknesses in how the API verifies identity — weak token handling, credential stuffing exposure, flawed JWT/session logic — the door before authorisation even begins. API4 Unrestricted Resource Consumption is the API version of denial-of-wallet and DoS: no rate limiting, no quotas, so an attacker (or a runaway client) can exhaust CPU, memory, or your metered third-party bills. API6 Unrestricted Access to Sensitive Business Flows is subtler and increasingly important: an API that exposes a valuable business action — buying limited stock, creating accounts, submitting reviews — without protection against automated abuse. There's no “vulnerability” in a single request; the flaw is that the flow can be run ten thousand times by a bot. Testing these needs a human thinking like an abuser, not a scanner checking signatures.
// 04 API7–API10 — SSRF, config, inventory & third parties
API7 Server-Side Request Forgery: the API fetches a URL supplied by the user without validation, letting an attacker make the server request internal systems or cloud metadata — a classic cloud-privilege-escalation stepping stone, as in SSRF against cloud metadata. API8 Security Misconfiguration: missing hardening, verbose errors, permissive CORS, default settings. API9 Improper Inventory Management is an API-specific gem: organisations lose track of their APIs — old v1 endpoints still live, undocumented “shadow” APIs, staging hosts exposed — and you can't protect what you don't know you run. API10 Unsafe Consumption of APIs flips the lens: your API trusts data from third-party APIs too readily, inheriting their compromise. Together these round out a list whose message is consistent — APIs fail on logic, trust and visibility, not just classic bugs.
// 05 How to test the API Top 10
The defining feature of API testing is that it's authorisation-centric and largely manual. The core technique: create multiple accounts at different privilege levels and systematically try to reach each other's objects (BOLA), read and write fields you shouldn't (property-level), and invoke privileged functions as a low-privilege user (function-level). Layer on rate-limit and resource-consumption probing, business-flow abuse (can this be automated at scale?), and checks for SSRF, misconfiguration and forgotten endpoints. Because the leading risks are logic and authorisation flaws that scanners can't reliably find, valid credentials and a human tester are non-negotiable. That's exactly how we run API penetration testing — per our methodology, with each finding reproduced and tied to real impact.
// 06 Frequently asked questions
What is the OWASP API Security Top 10?
A widely referenced list of the most critical API-specific security risks, maintained by OWASP. It exists because APIs fail differently from web apps — the biggest risks are authorisation flaws, not injection. The 2023 edition is led by BOLA and Broken Authentication and includes object property level authorisation, resource consumption, function level authorisation, business flows, SSRF, misconfiguration, inventory management and unsafe consumption of third-party APIs.
What is BOLA and why is it #1?
BOLA (Broken Object Level Authorization) is when an API fails to check that the authenticated user is allowed the specific object they request — change the ID in the request and read others' data. It's #1 because it's extremely common, easy to exploit, and leads to mass data exposure. Scanners can't find it reliably because only the application knows who should access what.
How do you test for API Top 10 risks?
Largely manually and authorisation-focused: create multiple accounts at different privilege levels and try to access each other's objects and functions, manipulate object properties, and call admin endpoints as ordinary users. Probe rate limiting and resource consumption, examine business flows for automation abuse, and check for SSRF, misconfiguration and exposed endpoints. Human-led testing with valid credentials is essential.
Are API risks different from the web app Top 10?
Yes. The general OWASP Top 10 covers web risks broadly; the API Security Top 10 focuses on API-based architectures. The difference is emphasis — for APIs, authorisation flaws (object, property and function level) plus resource consumption and business-flow abuse lead, while injection is relatively less prominent. Modern apps are API-driven, so both matter, but the API list better reflects where API breaches come from.
// 07 Related reading
- API penetration testing — scoped testing against this Top 10.
- BOLA that scanners miss and mass assignment.
- OWASP Top 10 in real engagements and the session management checklist.