When people say "OWASP 2019," they almost always mean the OWASP API Security Top 10 — 2019 edition, the project's first dedicated list of API-specific risks, and its headline finding was that broken authorization, not injection, is the number-one way APIs get breached. The flagship OWASP Top 10 for web applications had editions in 2017 and 2021 but not 2019, so a 2019 reference points squarely at the API list.
That distinction matters because the two projects address different things. The classic Top 10 covers web application risks broadly. The API Security Top 10, born in 2019, exists because APIs fail in ways a page-oriented list did not capture well — most of them centered on who is allowed to access which object.
Why an API-specific list was needed
By 2019, backends had shifted from server-rendered pages to APIs consumed by single-page apps and mobile clients. That changed the attack surface. In a page-based app, the server controls what a user sees. In an API-driven app, the client asks for specific objects by ID, and the server has to decide, on every request, whether this caller is allowed this object. When it does not check properly, an attacker just changes the ID.
The 2019 list captured this. The top two entries are both authorization failures, which was a deliberate signal: for APIs, access control is the dominant problem, ahead of the injection flaws that historically topped web lists.
The OWASP API Security Top 10 — 2019 categories
The full 2019 edition, in order:
- API1:2019 Broken Object Level Authorization (BOLA) — the server fails to verify that the caller owns or may access the specific object they requested by ID. The single most common and damaging API flaw.
- API2:2019 Broken User Authentication — weak or misimplemented authentication lets attackers assume identities or forge tokens.
- API3:2019 Excessive Data Exposure — the API returns more fields than the client needs and relies on the client to filter, leaking data to anyone reading the raw response.
- API4:2019 Lack of Resources and Rate Limiting — no limits on request size or frequency, enabling denial of service and brute force.
- API5:2019 Broken Function Level Authorization — a caller can invoke admin or privileged functions they should not reach, often just by calling a different endpoint.
- API6:2019 Mass Assignment — the API binds client-supplied fields directly to internal objects, letting attackers set properties they shouldn't (like
isAdmin). - API7:2019 Security Misconfiguration — default configs, verbose errors, missing headers, and open cloud storage.
- API8:2019 Injection — the classic SQL, NoSQL, and command injection, now demoted from its long-held top spot.
- API9:2019 Improper Assets Management — forgotten, undocumented, or deprecated API versions still exposed and unpatched (the "shadow API" problem).
- API10:2019 Insufficient Logging and Monitoring — attacks go undetected because nothing is recorded or watched.
The headline lesson: authorization dominates
Three of the ten (API1, API5, and arguably API6) are authorization failures, and the top spot went to BOLA. That is the enduring takeaway from the 2019 edition. Injection, the villain of a decade of web security training, sits at number eight. For APIs, the question "should this caller be allowed to do this to this object" is where the breaches happen.
BOLA is worth dwelling on because it is so easy to introduce. Consider an endpoint like this:
GET /api/accounts/12345/statements
If the server returns statements for account 12345 because the URL says so, without checking that the authenticated user actually owns account 12345, an attacker changes the number to 12346 and reads someone else's data. The fix is not clever — verify ownership on every object access — but it has to be enforced consistently on every endpoint, which is exactly where large APIs slip.
Testing for the 2019 risks
These flaws are largely invisible to tools that only look at code patterns, because whether authorization is "correct" depends on business logic. Detection usually needs dynamic testing against a running API with multiple user contexts:
- For BOLA and function-level auth: authenticate as user A, capture requests, then replay them with user B's token and see what comes back.
- For excessive data exposure: inspect raw API responses, not the rendered UI, for fields the client never displays.
- For improper assets management: enumerate old API versions (
/v1/,/v2/, staging hosts) that may still be live and unpatched.
This is where dynamic application security testing earns its keep — see our DAST overview for how running-app testing surfaces authorization flaws that static analysis misses.
2019 versus later editions
The API Security Top 10 was later revised (the 2023 edition), which reshuffled and renamed several categories — for instance introducing Server-Side Request Forgery and Unsafe Consumption of APIs, and merging some 2019 entries. If a requirement or checklist cites specific API numbers, confirm which edition it references, because API3 in 2019 is not API3 in 2023. But the 2019 core lesson — authorization first — carried straight through.
For where API testing fits in a full program, the DevSecOps pillars guide covers automating these checks in a pipeline.
FAQ
Was there an OWASP Top 10 for 2019?
Not for the flagship web application Top 10 — its editions are 2017 and 2021. The 2019 release was the first OWASP API Security Top 10, a separate project focused on risks specific to APIs. A reference to "OWASP 2019" almost always means that API list.
What is the number-one risk in the OWASP API Security Top 10 2019?
Broken Object Level Authorization (BOLA), where the server fails to verify that the caller is allowed to access the specific object they requested by ID. It is both the most common and the most damaging API flaw.
How is the API Security Top 10 different from the regular OWASP Top 10?
The regular Top 10 covers web application risks broadly, historically led by injection. The API Security Top 10 focuses on API-specific failures and is led by authorization flaws, reflecting how API-driven apps expose objects directly to clients.
Is the 2019 edition still relevant given the 2023 update?
The 2023 edition reorganized and renamed categories, so cite the correct edition when a checklist references specific numbers. But the central 2019 insight — that authorization, not injection, is the dominant API risk — remains accurate.