The OWASP API Security Top 10 (2023), explained with the breaches that prove it

Why APIs have a list of their own

The OWASP Top 10 for web applications is organized around what an anonymous browser can send. An API has no browser, and its callers are mostly authenticated. Salt Security reports that nearly all of the attack attempts its labs analyze originate from authenticated sources: not an outsider probing a login page, but a customer, a trial account or a partner using credentials they are entitled to and then asking for objects they are not.

That changes what a test has to look for. Injection and misconfiguration still matter, and scanners are good at both. What scanners cannot do is decide whether account A should be able to read object 41,932, because only your business knows the answer. Six of the ten categories in the API list are, at root, authorization questions. That is the difference the list exists to capture.

The 2023 edition reached stable release on 5 June 2023 and is published by the OWASP Foundation under Creative Commons Attribution-ShareAlike 4.0. The category names and the quoted one-line definitions below are the Foundation’s; the probes, commentary and incident mapping are ours.

What changed between 2019 and 2023

If you are comparing a report written against the older list, three changes matter. OWASP merged two categories, added one, and added another for a threat that did not previously exist at scale.

• Excessive Data Exposure and Mass Assignment became a single category, API3:2023 Broken Object Property Level Authorization. The release notes give the reason: OWASP was “focusing on the common root cause: object property level authorization validation failures”. Reading too much and writing too much are the same missing check seen from two directions.
• API6:2023 Unrestricted Access to Sensitive Business Flows is new. OWASP created it “to address new threats, including most of those that can be mitigated using rate limiting”. It is not about request volume as such; it is about what a business flow is worth when it is run by a script.
• API10:2023 Unsafe Consumption of APIs is new, added because “attackers have started looking for a target’s integrated services to compromise those, instead of hitting the APIs of their target directly”. It is a supply-chain category with an API shape.

The ten categories at a glance

One row per category: the official name, the probe that opens the question, and where the category has already caused a public incident. The incident column cites disclosures listed in the sources at the end of this guide.

API1: the identifier nobody checked

OWASP describes the category plainly: “APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues.” The endpoint takes an identifier, looks the object up, and returns it. The check that the caller is entitled to that particular object is either missing or applied somewhere the request can avoid.

The McDonald’s McHire case from July 2025 is the clearest recent example, because the researchers documented both halves. Default credentials on the Paradox.ai administrative login gave a session, and from there an object-level flaw on PUT /api/lead/cem-xhr returned other people’s applications simply by decrementing the lead identifier in the request body. The researchers put the exposure at more than 64 million applicants. The disclosure and the fix took a few hours; the flaw had presumably been there for years.

Optus in 2022 is the same shape at national scale. Australia’s communications regulator found that a coding error in 2018 broke an access control on an API. The fix reached one domain in 2021, but the internet-facing target domain “was not decommissioned despite a lack of any need for it”. 9.5 million people were affected, and the regulator described the method as a simple process of trial and error.

Testing for API1 is mechanical and slow, which is why it is the first thing a cheap engagement drops. Every object type is requested from an account that should not own it, in both directions, and in a multi-tenant system from a second tenant as well. Sequential identifiers make it faster; UUIDs do not make the bug go away, they only make it harder to find by guessing, which is not the same as fixing it.

API2: the endpoint that never asked

OWASP: “Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws.” In practice this splits into two very different findings. One is a token-handling flaw: an unvalidated signature, an accepted algorithm change, an expiry that is never enforced, a refresh token that outlives revocation. The other is far more common and far more embarrassing: a route that simply does not require a token.

Twilio confirmed the second kind in July 2024, stating that “threat actors were able to identify data associated with Authy accounts, including phone numbers, due to an unauthenticated endpoint”. The resulting dataset held 33,420,546 rows of multi-factor authentication phone numbers. Trello had the same problem the same year: an open endpoint mapped any email address to an account, and feeding it 500 million addresses produced 15,115,516 matching records.

Peloton in 2021 shows what an unauthenticated read endpoint leaks when the data model is rich. Unauthenticated endpoints, including api.onepeloton.com/api/user/search/, returned user IDs, instructor IDs, group membership, location, workout statistics, gender and age, and did so for profiles their owners had set to private. The disclosure timeline is instructive on its own: reported on 20 January, partially and silently fixed on 2 February, largely fixed within seven days of the press becoming involved.

API4 and API6: the flow nobody metered

API4:2023 Unrestricted Resource Consumption is the availability and cost category. OWASP notes only that “successful attacks can lead to Denial of Service or an increase of operational costs”, which understates how often it is the enabling condition for a data breach rather than an outage.

Dell in 2024 is the canonical case. Fake partner accounts were approved within 24 to 48 hours, then used against a partner-portal API at 5,000 requests per minute for roughly three weeks, retrieving 49 million records including names, service tags, installed locations and order numbers. The portal reportedly had no rate limiting. No individual request in that campaign was malicious. The bug was that nobody had decided how many lookups a partner account should be allowed to perform in a day.

That decision is what API6:2023 is about. OWASP: “APIs expose a business flow without compensating for how the functionality could harm the business if used excessively in an automated manner.” Checkout, referral credit, invitation, stock reservation, bulk lookup, price discovery: each of them is fine at human speed and is a product in its own right at machine speed. Testing it means modeling your flows first, which is why a tester will ask which endpoints make or cost money.

API8: the flag that said authentication was optional

OWASP: “Software and DevOps engineers can miss these configurations, or don’t follow security best practices when it comes to configuration.” Salt Security reports that around two-thirds of the attacks it observes exploit exactly this category, which makes it the most-attacked item on the list even though it is the eighth.

ServiceNow in June 2026 is a textbook instance. A scripted REST endpoint, /api/now/related_list_edit/create, shipped with requires_authentication set to false. Exploitation was observed on 2 and 3 June and a hotfix followed on 5 June; ServiceNow stated that “a subset of customer instances were queried successfully as part of this activity”. Nothing was wrong with the platform’s authentication design. One route had a boolean set the wrong way.

This is why a test enumerates routes rather than services. Asking “is this API authenticated?” gets a yes. Asking the same question of each of 240 individual operations, including the ones added last sprint by a different team, gets a more useful answer.

API10: the integration you did not write

OWASP added this category because “developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards”. The 2025 Salesloft Drift campaign is the version of this that keeps security teams awake.

Google’s threat intelligence team reported that, between 8 and 18 August 2025, the actor tracked as UNC6395 used OAuth tokens compromised from the Salesloft Drift third-party application to export data from Salesforce customer instances. The exports were then searched specifically for AWS access keys, passwords and Snowflake tokens. The tokens were revoked on 20 August. None of the affected organizations had a vulnerability in their own code. They had granted an integration a token, and the integration was the way in.

Testing API10 means asking what each integration can reach, what scope its token actually carries versus what it needs, how quickly a token can be revoked, and what your API does with data that arrives from a partner rather than from a user.

What the list does not cover

A top ten is a starting point, not a scope. Four things fall outside it and still belong in a serious engagement.

• Business logic beyond API6. Flows that are individually authorized and individually rate-limited can still combine into something you would never approve. That needs a person who has read your product documentation.
• Secrets and key management. Keys in client bundles, long-lived tokens with no rotation and shared service credentials sit across several categories without belonging cleanly to any of them.
• The consumer side of your own API. What your mobile app or partner SDK does with the data it receives is not covered by a test of the server.
• Availability engineering. API4 covers whether limits exist. Whether they hold under a distributed attack is a different exercise with different rules of engagement.

Verify that every HTTP response with a message body contains a Content-Type header field that matches the actual content of the response, including the charset parameter.OWASP ASVS 5.0, requirement V4.1.1 (Level 1)

For depth beyond the top ten, the OWASP Application Security Verification Standard 5.0, released on 30 May 2025, is the better instrument. Its chapter V4 covers API and web service security specifically, with sections on generic web service security, HTTP message structure validation, GraphQL and WebSocket. A report that maps findings to both the Top 10 and ASVS requirements is more useful to an engineer, because ASVS states the fix as a testable requirement.

How to use the list without turning it into a checklist

The failure mode of any top ten is that it becomes a tick sheet. Ten boxes get marked covered, and the coverage claim hides how thin the coverage was. Three habits prevent that.

• Ask for the coverage matrix, not the category list. “API1 tested” means nothing without the count of object types and roles behind it.
• Insist that each category be scoped to your API. API7 in a service with no outbound fetches is a one-line note; API7 in an integration platform is two days of work.
• Treat categories with no findings as a question. Zero findings in API5 across a five-role API is either excellent engineering or a pass that was never run, and the report should let you tell which.

The self-check on the scope estimator exists for this purpose: mark how your last test covered each of the ten categories, and read the result as a list of questions for the next engagement rather than as a score.