Most teams have read the OWASP Top 10 for web apps. Far fewer have internalized the API Security list. That gap is where attackers operate. The broader Web Apps list refreshed in 2021; the API list has not been refreshed since 2019. That lag is itself a signal: the problem hasn't changed because the root cause—broken access control—requires architectural fixes, not patches.
Attackers don't care that the document is stale. They care that object-level checks are skipped, authorization logic is tangled, and logging is thin. The categories below come from the 2019 OWASP API Security Top 10 as analyzed by Veracode, and they map closely onto what appears in real incident postmortems.
Quick take
- Six of the top seven API risks center on unintended data exposure through broken authentication or authorization.
- SQL injection—historically first on web app lists—has dropped to third place on the Web Top 10 and eighth on the API list.
- The top five API risks rarely yield code execution; they yield data theft.
- Standard SAST and DAST tools struggle to catch the access-control flaws that dominate the API list.
Why the lists diverge
OWASP publishes separate lists because web apps and APIs fail differently. A browser-facing form has presentation logic. An API endpoint often has nothing between it and the request but a token. The 2019 API list ranks each category by frequency and severity of outcome. Broken Object Level Authorization sits at the top because the blast radius is large and the fix is rarely automatic.
The lists are revised every two to three years. Injection has visibly receded because frameworks ship defaults that block naive SQLi. The flaw class hasn't vanished—volume just dropped. APIs tell a different story: the dominant risks haven't shifted since 2019 because the problem isn't parser bugs. It's policy—who can read or write which object.
The dominant category: broken object-level authorization
Object-level authorization (API1-2019) is the risk to embed in your team's muscle memory. Veracode illustrates it simply: a request to read a user record scoped by organization. If the server checks only the token and trusts the path parameter, a user in tenant A can retrieve records from tenant C. That single gap has driven most major multi-tenant data leaks in recent years.
Authentication failures (API2-2019) sit close behind. Failure modes include credential stuffing without rate limiting, weak password enforcement, JWTs with "alg":"none", and tokens exposed in URLs. These are catchable with automated scanning. The harder class is broken function-level authorization (API5-2019), where a standard user can call admin endpoints because the route checks only "is authenticated," not "has permission."
Who should care
| Audience | Why this matters | Primary risk |
|---|---|---|
| B2B SaaS teams | Multi-tenant architectures amplify object-level authorization gaps | Cross-tenant data leakage |
| Mobile and SPA developers | Client-side logic is thin; APIs carry the load | Unintended data exposure |
| Security operations | Alert fatigue from scanner noise; real gaps hide in authz logic | Breaches that bypass tooling |
| DevSecOps programs | "Shifted left" scanning misses what OWASP API Top 10 actually tests | False confidence in coverage |
The scanning gap
The OWASP API Top 10 exposes a uncomfortable truth: most tools find syntax, not policy. SAST and DAST can flag missing auth decorators or weak JWT configuration. They cannot tell you whether a decorator sits in the right place, or whether a given user should reach a given function. That's a design question. It's also why the top five API risks are not scanner output—they are architecture decisions made at design time and enforced at runtime.
Teams that bought a scanner, ticked the box, and shipped the API are optimizing for the wrong risk. The trade-off is real: scanning catches some classes cheaply, but dominant API risks need design review, threat modeling, and targeted authorization tests.
What to watch next
Watch for an OWASP API Security refresh. The 2019 list is overdue, and a new ranking will likely elevate authorization categories further. Draft discussions have surfaced "unrestricted access to sensitive business flows" as a candidate. If your program treats API security as a scanner output, reframe it as a design checklist. That shift is where defender advantage begins.
Key takeaways
- Treat object-level authorization as a code invariant, enforced in the data access layer, not at the edge.
- Stop relying on SAST and DAST alone for API access-control coverage; add design review and targeted authorization tests.
- Plan around a likely API Top 10 refresh that elevates broken authorization categories further.
- Prioritize API1 and API2 remediation first; they dominate real incidents even though they don't yield code execution.
Frequently asked questions
What is the OWASP API Security Top 10?
It is OWASP's ranked list of the ten most critical security risks specific to APIs, last refreshed in 2019 as analyzed by Veracode.
Why is Broken Object Level Authorization listed first?
Because it is both common and directly leads to cross-customer data access—a typical severe-data-breach outcome that Veracode highlights as the primary risk for API-driven applications.
Can SAST and DAST catch the top API risks?
Partially. They can flag issues like weak JWT handling or misconfigurations, but Veracode notes they struggle to identify access-control flaws where the question is whether a user should have access, not whether a syntax error exists.
Do the top API risks lead to remote code execution?
Generally no. According to Veracode's analysis, the top five API risks more often lead to data exposure, PII disclosure, or sensitive data leaks rather than server compromise.
How does the API Top 10 differ from the Web Top 10?
The Web list is dominated by injection and misconfiguration alongside access control; the API list is dominated by broken authorization and data exposure, with injection falling to eighth place. **END**