The OWASP API Top Ten is the industry reference list of the ten most common and damaging ways REST and GraphQL APIs get attacked, and the current version is the 2023 edition. If you build backend services, it maps almost exactly to the bugs that show up in real breach reports: not exotic memory corruption, but authorization checks that were never written, endpoints nobody remembered to retire, and rate limits that don't exist. The list was rebuilt in 2023 after the original 2019 edition, and the reshuffle tells you where attackers actually spend their time. Authorization now dominates the top of the list.
Web apps have their own OWASP list, but APIs earn a separate one because the threat model is different. There's no browser rendering the response, no server-side templating, and the client is usually another program that will happily send malformed or malicious input all day. The vulnerabilities that matter are structural, not cosmetic.
Why authorization owns the top of the list
Three of the ten categories are authorization failures, and the number-one entry, API1:2023 Broken Object Level Authorization (BOLA), is the single most exploited API flaw in the wild. BOLA happens when an endpoint like GET /api/orders/1043 returns the order without checking that the authenticated user actually owns order 1043. Change the ID to 1044 and you're reading someone else's data. It's trivially easy to find with a script and devastating at scale.
The related entries are API3:2023 Broken Object Property Level Authorization (the API returns or accepts fields the user shouldn't touch, like mass-assigning isAdmin: true) and API5:2023 Broken Function Level Authorization (a regular user can call an admin-only route because the check lives in the UI, not the server). All three share a root cause: the server trusts the request to be well-behaved instead of independently verifying what this specific user is allowed to do with this specific resource.
The fix is not a library. It's a discipline: every handler that touches a resource re-derives authorization from the session, never from an ID in the URL or body. Enforce it with a shared middleware or policy layer so a new endpoint can't skip the check by omission.
Authentication is still on the list, just lower
API2:2023 Broken Authentication covers the classics: weak JWT validation, tokens that never expire, credential-stuffing endpoints with no throttling, and password-reset flows that leak whether an account exists. A common modern variant is accepting a JWT whose signature you never actually verify, or trusting the alg: none header. If your token library lets an attacker choose the algorithm, treat that as a critical finding.
Practical checks: verify signatures against a pinned key, set short access-token lifetimes with refresh rotation, and rate-limit every authentication endpoint including refresh and reset. The /login route is not the only door.
The consumption and business-flow entries
API4:2023 Unrestricted Resource Consumption is what used to be called "lack of resources and rate limiting." An endpoint that runs an unbounded database query, accepts a 500 MB upload, or lets a caller request ?limit=10000000 can be turned into a denial-of-service tool or a way to run up your cloud bill. Every API should have request-size limits, pagination caps, timeouts, and per-client rate limits enforced at the gateway.
API6:2023 Unrestricted Access to Sensitive Business Flows is the subtler one, and it's new in 2023. The individual requests are all authorized and valid; the abuse is in volume and intent. Think of a bot buying every concert ticket, mass-creating fake accounts, or scraping a full catalog. There's no single "vulnerable" call, so you defend it with behavioral controls: device fingerprinting, CAPTCHAs on high-value flows, and anomaly detection on request patterns.
Server-Side Request Forgery earns its own entry
API7:2023 Server Side Request Forgery (SSRF) made the list because so many APIs fetch URLs on behalf of clients: webhooks, image proxies, PDF generators, "import from URL" features. If the server takes a user-supplied URL and requests it without validation, an attacker points it at http://169.254.169.254/ to steal cloud metadata credentials, or at internal services behind the firewall. This is exactly the failure I dig into in our Python URL validator guide — validating a URL against an allowlist before you fetch it is the whole ballgame. Block redirects to internal ranges, resolve DNS before connecting, and never let user input select the host you connect to.
Misconfiguration, inventory, and third-party consumption
The last three round out the operational side. API8:2023 Security Misconfiguration is the grab-bag: verbose error messages that leak stack traces, missing security headers, CORS set to * with credentials, unpatched frameworks, and debug endpoints left enabled in production.
API9:2023 Improper Inventory Management is quietly one of the most dangerous. It's the /api/v1/ endpoint everyone forgot when they shipped /api/v2/, the staging host with production data, the internal admin API exposed to the internet. You cannot secure what you don't know exists. Maintain an accurate inventory of every host, version, and endpoint, and decommission old ones deliberately. Automated API discovery and an up-to-date software bill of materials both feed this.
API10:2023 Unsafe Consumption of APIs is the flip side: your API trusts data from a third-party API too much, skipping validation on responses from a partner or an internal microservice. Treat every upstream response as untrusted input, especially before you use it in a query, a redirect, or a template.
Turning the list into a workflow
The Top Ten is a checklist, not a scanner. To operationalize it, map each category to a concrete control and a test. BOLA and function-level authorization get automated tests that replay a request with a different user's token and assert a 403. Resource consumption gets load tests that confirm pagination and size limits hold. SSRF gets a unit test on your URL validator. Inventory gets a scheduled discovery scan that diffs against your known route list.
Dependency-driven categories like misconfiguration and unsafe consumption also benefit from continuous dependency and vulnerability scanning in CI; an SCA tool such as Safeguard can surface a vulnerable framework version or a transitive package that reintroduces a fixed CVE before it ships. But no tool replaces writing the authorization check. Automated scanners are good at finding known-CVE patterns and bad at understanding your business logic, which is precisely where BOLA and business-flow abuse live.
If you're building an API security program from zero, start where the attackers do: prove that object-level authorization holds on every resource endpoint, then work down the list. The rest is important, but broken authorization is what gets you breached first.
FAQ
What is the difference between the OWASP Top 10 and the OWASP API Top Ten?
The original OWASP Top 10 targets web applications broadly (injection, XSS, and so on), while the OWASP API Top Ten focuses on the failures specific to API backends, where authorization gaps and inventory problems dominate rather than browser-rendered issues.
What is the most common OWASP API Top Ten vulnerability?
Broken Object Level Authorization (BOLA), the number-one entry, is the most frequently exploited. It occurs when an endpoint returns or modifies a resource based on an ID in the request without confirming the caller actually owns that resource.
Is there a newer version than the 2023 OWASP API Top Ten?
As of mid-2026 the 2023 edition remains the current published version. It replaced the 2019 edition and added categories for unrestricted access to sensitive business flows and unsafe consumption of APIs.
Can a scanner fully cover the OWASP API Top Ten?
No. Scanners catch misconfiguration, known-CVE dependencies, and some injection patterns, but they cannot verify your business-specific authorization logic. BOLA and business-flow abuse require deliberate design and targeted tests.