In September 2022, Optus exposed the personal data of 9.8 million Australian customers because an internet-facing API had no authentication requirement — anyone who found the endpoint could pull names, dates of birth, and passport numbers. Four months later, T-Mobile disclosed that an attacker had abused a single API for six weeks to scrape records on 37 million accounts, again without needing to authenticate. Neither breach involved a zero-day. Both map directly to categories in the OWASP API Security Top 10, the reference list maintained by the Open Worldwide Application Security Project for the risks that recur across API-first architectures. The current edition, finalized in June 2023, replaced the original 2019 list after the working group reviewed over 100 real-world incidents and hundreds of community submissions. Below is what each of the highest-impact categories actually means, in production terms.
What is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a ranked list of ten API-specific vulnerability classes, published separately from the better-known OWASP Top 10 for web applications because APIs fail in different ways than traditional web apps. The project started in 2019 under contributors including Erez Yalon and Inon Shkedy, and it was rewritten for 2023 based on a data call that pulled in incident reports, bug bounty writeups, and penetration test findings from companies running production API fleets. Unlike the general web Top 10, which leans on injection and XSS, the API list is dominated by authorization failures — five of the ten 2023 categories are variations on "the API let a user access or do something they shouldn't have." That skew reflects how APIs actually get breached: not through exotic exploits, but through endpoints that trust a client-supplied ID or role claim without checking it against the resource being requested.
What changed between the 2019 and 2023 editions?
The 2023 edition consolidated some 2019 categories and added two new ones. Broken User Authentication was renamed Broken Authentication (API2), Excessive Data Exposure and Mass Assignment were merged into Broken Object Property Level Authorization (API3), and Insufficient Logging & Monitoring dropped out of the top ten entirely, replaced by Unrestricted Access to Sensitive Business Flows (API6) and Unsafe Consumption of APIs (API10). Server Side Request Forgery (API7) was added as a standalone category for the first time, acknowledging how often API integrations forward user-supplied URLs to internal services. Improper Assets Management was renamed Improper Inventory Management (API9) to emphasize that most inventory failures now come from shadow and zombie API versions rather than missing documentation. The reordering matters for prioritization: Broken Object Level Authorization kept the #1 spot across both editions, which is the strongest signal in the document that authorization checks, not input sanitization, are the primary API attack surface.
What is Broken Object Level Authorization and why is it ranked #1?
Broken Object Level Authorization (BOLA) is ranked #1 because it is the easiest API flaw to find and the hardest to catch with automated scanners, and it shows up in nearly every major API breach of the last five years. BOLA happens when an endpoint like GET /api/invoices/{id} checks that the caller is authenticated but never checks that the caller actually owns invoice {id} — so incrementing the ID in the URL returns someone else's data. The USPS Informed Delivery API disclosed this exact pattern in November 2018, exposing account data for roughly 60 million users to anyone who registered an account and changed a request parameter. Peloton hit the same class of bug in January 2021: its API returned private profile data — including age, gender, and location — for any user ID queried, regardless of that user's privacy settings, affecting an estimated 3 million accounts before a fix shipped. BOLA is structurally hard to catch with a web application firewall because the request looks syntactically identical to a legitimate one; the only way to catch it is to know, at the code level, which object each authenticated user is entitled to reach.
How does Broken Authentication lead to full account takeover?
Broken Authentication (API2) leads to takeover because it targets the mechanisms that establish identity in the first place — weak JWT validation, credential stuffing with no rate limiting, and password-reset or API-key flows that skip verification. In the T-Mobile case disclosed on January 19, 2023, the abused API endpoint required no authentication token at all for the queries the attacker was running, so there was no login event, failed password, or session anomaly for a SOC to catch. A 2023 review of API-focused bug bounty reports by Traceable found authentication and authorization issues accounted for the largest single share of submitted findings, ahead of injection-class bugs. Common root causes include APIs that accept unsigned or "none"-algorithm JWTs, API keys that never expire and are never rotated, and mobile-app API clients that embed a static secret extractable by anyone who decompiles the APK. Because these tokens often carry broad scopes, a single compromised credential can enumerate an entire customer database rather than one account.
What is Unrestricted Resource Consumption, and how is SSRF different?
Unrestricted Resource Consumption (API4) is different from SSRF (API7) because one drains your infrastructure and the other turns your API into a proxy for attacking systems you didn't mean to expose. API4 covers endpoints with no limits on payload size, response size, number of records returned per request, or number of requests per client — a report-generation endpoint that lets a caller request a 500,000-row CSV export with no pagination cap is a textbook example, and it can be triggered by a single authenticated free-tier user, no botnet required. API7, Server Side Request Forgery, was added in 2023 specifically because so many "integration" and "webhook" API features accept a URL from the client and then fetch it server-side — image-import endpoints, PDF-generation services, and SSO metadata fetchers are recurring offenders. Capital One's 2019 breach, which exposed data on over 100 million customers, involved an SSRF-style request against cloud metadata endpoints that let the attacker retrieve temporary credentials; while that incident predates the API7 category by four years, it's the reference case the working group cites for why SSRF needed its own line item rather than staying folded into generic misconfiguration.
Why do Improper Inventory Management and Unsafe API Consumption keep causing breaches nobody expected?
Improper Inventory Management (API9) and Unsafe Consumption of APIs (API10) keep causing breaches because both describe blind spots — APIs teams don't know they're running, and third-party APIs teams trust without verifying. API9 covers zombie endpoints: an old /v1/ API version left reachable after everyone moved to /v2/, still pointed at a database that never got the newer version's access controls. Security teams routinely find that automated API discovery surfaces 20-40% more live endpoints than what's documented in the API gateway or spec files, and the undocumented ones are disproportionately the ones missing rate limiting or auth middleware added later. API10 covers the inverse problem: an API you consume, not one you expose. If your backend calls a third-party enrichment API and trusts its response without validating schema, size, or redirect behavior, that upstream API becomes an injection point into your own system — exactly the mechanism the 2023 working group cited when adding the category, pointing to incidents where a compromised or malicious upstream partner API returned payloads that downstream services processed unsafely.
How Safeguard Helps
Safeguard maps these OWASP API risks to what's actually reachable in your running services, rather than flagging every endpoint with a missing decorator as equally urgent. Griffin AI reads your API route definitions and authorization middleware together to flag BOLA and broken function-level authorization gaps — the #1 and #5 items on the 2023 list — with the specific code path that would need to execute for exploitation, cutting through the noise a generic API scanner produces. Reachability analysis distinguishes an internet-facing endpoint missing a rate limit from an internal admin route behind three auth layers, so Unrestricted Resource Consumption findings get triaged by actual exposure instead of pattern-matching alone. SBOM generation and ingest give you the API inventory piece of API9 for free, correlating deployed service versions against what's documented so zombie API versions surface automatically. When Safeguard confirms a fix, it opens an auto-fix pull request with the authorization check or rate-limit middleware already written, so remediation ships in the same sprint the finding is triaged rather than sitting in a backlog.