In November 2022, an attacker abused a single unauthenticated API endpoint at T-Mobile to pull records on 37 million customer accounts before the company detected the intrusion on January 5, 2023. The flaw wasn't a zero-day or a novel exploit chain — it mapped directly to Broken Object Level Authorization, the #1 risk on the OWASP API Security Top 10. That list, maintained by the OWASP API Security Project and last revised in 2023 — and often shortened to the OWASP API Top 10 — catalogs the ten most common ways APIs get breached, from missing authorization checks to unrestricted business-logic abuse. APIs now carry more backend traffic than traditional web front ends, and Gartner has flagged API abuse as one of the fastest-growing attack vectors against enterprise data. This post breaks down what's actually in the 2023 OWASP API Security Top 10, what changed from the 2019 edition, and which risks have caused the most documented breaches — with named incidents, not hypotheticals.
What Is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a standardized ranking of the ten most critical security risks specific to APIs, published by the OWASP API Security Project, with editions released in 2019 and 2023. It's a sister project to the better-known OWASP Top 10 for web applications — which is why you'll see both "OWASP API Security Top 10" and the shorter "OWASP API Top 10" used for the same list — but it exists separately because APIs fail in different ways: they expose raw data models directly, they're consumed by machines that can hit them thousands of times per second, and a single broken authorization check can expose every record in a database rather than one rendered page. The current (2023) list, in order, is: Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs. Security teams use it as a shared vocabulary for API risk assessments, pen test scoping, and secure-development training, the same way they've used the web Top 10 since 2003.
What Changed Between the 2019 and 2023 OWASP API Security Top 10?
Four categories changed in the 2023 update, while Broken Object Level Authorization held the #1 spot in both editions. OWASP merged 2019's Excessive Data Exposure and Mass Assignment into a single category, Broken Object Property Level Authorization (API3:2023), because both stemmed from the same root cause — APIs returning or accepting object fields without per-property checks. Lack of Resources & Rate Limiting was renamed and broadened into Unrestricted Resource Consumption (API4:2023) to cover cloud compute and storage costs, not just request volume. Two entirely new categories appeared: Unrestricted Access to Sensitive Business Flows (API6:2023), covering abuse of legitimate features like bulk purchasing or account creation at bot scale, and Server Side Request Forgery (API7:2023), split out as its own entry for the first time. Meanwhile, two 2019 categories — Injection (API8:2019) and Insufficient Logging & Monitoring (API10:2019) — were dropped as standalone Top 10 entries, folded into broader guidance rather than removed as concerns.
Which OWASP API Risk Causes the Most Real-World Breaches?
Broken Object Level Authorization (BOLA) causes more documented API breaches than any other category on the list. In the T-Mobile incident disclosed in January 2023, the attacker queried an API for 37 million customer accounts by manipulating identifiers the server never re-validated against the requester's own permissions. In September 2022, Optus disclosed a breach affecting roughly 9.8 million current and former customers in Australia, traced to an internet-facing API that required no authentication token at all to return customer records. In May 2021, security researchers at Pen Test Partners showed that Peloton's API let any authenticated user pull the private profile data of any other Peloton user — including public figures — by changing a user ID in the request, exposing data tied to roughly 3 million accounts. BOLA succeeds in each case for the same reason: the API confirms the caller is logged in, but never confirms the caller is allowed to see that specific object.
How Does Broken Authentication Differ From Broken Object Level Authorization?
Broken Authentication (API2:2023) fails before identity is ever established, while BOLA (API1:2023) fails after identity is established but ownership isn't checked. Broken Authentication covers weaknesses like unsigned or weakly signed JWTs, credential stuffing against login endpoints with no rate limiting, password reset flows that leak whether an account exists, and API keys that never expire or rotate. BOLA covers the opposite problem: the requester is who they claim to be, they're holding a valid token, but the API trusts an ID in the URL or payload — /api/invoices/88213 — without checking that invoice 88213 actually belongs to that account. A single API endpoint can suffer from both at once, which is why OWASP ranks them as the top two risks rather than treating one as a subset of the other; fixing weak authentication does nothing to stop a legitimately authenticated user from walking through every record in the database.
What Is Server-Side Request Forgery and Why Was It Added in 2023?
Server-Side Request Forgery (SSRF, API7:2023) is a flaw where an API fetches a remote resource — a webhook callback, an image URL, a PDF source — without validating that the destination is safe, letting an attacker redirect that request to internal infrastructure. The most cited real-world case remains the 2019 Capital One breach, where an attacker used an SSRF flaw in a misconfigured web application firewall to query the AWS instance metadata service, retrieve temporary credentials, and exfiltrate data on roughly 106 million customers, resulting in an $80 million OCC penalty and a separate $190 million class-action settlement. OWASP split SSRF into its own 2023 category because the pattern moved from a rare edge case into a routine feature: APIs that accept a callback URL for webhooks, fetch a profile picture from a link, or generate documents from a remote template are now common, and each one is a candidate for forcing the server to reach internal-only endpoints, cloud metadata services, or private admin panels that were never meant to be internet-reachable.
How Should Security Teams Prioritize Which OWASP API Risks to Fix First?
Teams should triage by exploitability and exposure rather than working straight down the numbered list, starting with authorization flaws on internet-facing endpoints — API1, API2, and API5 — because those require no special access to exploit and directly expose data. Unrestricted Resource Consumption and Unrestricted Access to Sensitive Business Flows (API4 and API6) come next, since they enable account-takeover-adjacent abuse like credential stuffing at scale or inventory-hoarding bots, even without a classic data leak. Server-Side Request Forgery (API7) deserves early attention on any API that accepts a URL, file path, or callback address as input, given its track record of pivoting into cloud metadata theft. Hygiene issues — Security Misconfiguration and Improper Inventory Management (API8 and API9) — matter most as force multipliers: an undocumented staging API with the same authorization bug as production doubles the blast radius. Ranking by what's reachable from the public internet, and what an exploit would actually expose, produces a materially different priority order than ranking by OWASP's list number alone.
How Safeguard Helps
Safeguard maps OWASP API Security Top 10 categories to your actual API surface instead of leaving teams to interpret the list manually. Reachability analysis determines whether a vulnerable code path — a missing authorization check, an unvalidated URL fetch — is actually invoked by an exposed endpoint, so BOLA and SSRF findings get triaged by real exploitability instead of static severity scores. Griffin AI reviews API route handlers and authorization middleware to flag broken object-level and function-level checks before they reach production, and generates auto-fix PRs that add the missing ownership or scope check directly in your code review flow. SBOM generation and ingest keep an accurate, continuously updated inventory of every API dependency and third-party library in play, closing the Improper Inventory Management gap that lets shadow and zombie APIs go unnoticed. Together, these capabilities turn the OWASP API Security Top 10 from a checklist into a set of prioritized, actionable fixes tied to what's actually deployed and reachable.