Why API security is a problem of its own: the OWASP API Security Top 10 (2023)

Protecting a web application and protecting an API are not the same job. Classic web security tooling mostly hunts for signature-based attacks like XSS and SQL injection, but the real weakness in most APIs hides in the authorization logic, and no signature catches that. APIs are the front door of nearly every modern application today, and they are also the target attackers reach for first. In one industry survey, 37% of organizations reported at least one API breach in 2024, up from 17% the year before. That gap is why OWASP publishes a separate API Security Top 10 alongside its web list. The current edition was refreshed in 2023 and ranks ten risks specific to APIs.

Why an API is a different attack surface

On a classic web page the server renders the HTML and sends a finished screen to the browser; data the user should not see often never reaches the page at all. An API does the opposite. It hands raw data and object identifiers straight to the client. On an endpoint like /api/invoices/1043, changing 1043 to 1044 takes a second. If the server does not ask "is this user allowed to see this record?" on every single request, someone else's invoice lands on the screen. Worse, an attacker does not do this by hand. They script it at machine speed, thousands of records a second.

The number-one risk: BOLA

The risk at the top of the list, and by far the most common, is Broken Object Level Authorization (BOLA). It happens when an API exposes an object by its ID but never checks that the caller actually owns that object. Industry data attributes roughly 40% of all API attacks to BOLA alone. The fix sounds simple but gets skipped constantly: the authorization check has to run on the server, on every request, not in the client by "hiding the button." Hiding a control in the front end is not security, because the API can be called directly.

37 million accounts: the T-Mobile case

The consequences are concrete. In January 2023 T-Mobile disclosed that data from about 37 million customer accounts had been stolen through a single API. The attacker began pulling data around November 25, 2022, and the company only noticed on January 5, 2023, cutting off access a day later. In other words, the flaw leaked data undetected for roughly six weeks. The exposed fields included names, addresses, email, phone numbers, dates of birth and account numbers.

49 million records: the Dell case

In May 2024 Dell confirmed that a partner-portal API had been abused to scrape around 49 million customer records. The attacker first registered accounts under fake company names and got into the portal within two days, with no verification (broken authentication). Then they wrote a program that generated 7-digit service tags and, because there was no rate limiting, fired 5,000 requests a minute for three straight weeks to harvest records one by one. Two flaws stacked here: weak authentication and a complete absence of rate limits.

Authentication, authorization and too much data

Second on the list is Broken Authentication: tokens generated poorly, sessions that never expire, predictable identity flows. Third is Broken Object Property Level Authorization (BOPLA), which merges two older problems, returning more data than needed and mass assignment. Say the API sends back a user object as-is, with an isAdmin field included; even if the front end never shows it, the raw JSON still carries it. Or the API blindly saves every field it receives, and an attacker adds "role":"admin" to the request to escalate. The right approach is to allowlist exactly which properties can be read and written.

The OWASP API Security Top 10 (2023)

The list covers ten API-specific risks:

1. API1 Broken Object Level Authorization (BOLA): object ownership never verified.
2. API2 Broken Authentication: the authentication mechanism built incorrectly.
3. API3 Broken Object Property Level Authorization: excessive data exposure and mass assignment.
4. API4 Unrestricted Resource Consumption: missing rate limits and quotas (DoS and cost).
5. API5 Broken Function Level Authorization: role- and function-level permission gaps.
6. API6 Unrestricted Access to Sensitive Business Flows: automated abuse of critical business flows.
7. API7 Server Side Request Forgery (SSRF): using the server through an unvalidated URI.
8. API8 Security Misconfiguration: wrong or incomplete configuration.
9. API9 Improper Inventory Management: forgotten and undocumented endpoints.
10. API10 Unsafe Consumption of APIs: blind trust in third-party APIs.

Rate limits and business-flow abuse

The fourth risk, Unrestricted Resource Consumption, is exactly what played out at Dell: without rate limits and quotas, a single endpoint becomes both a denial-of-service tool and a way to run up your bill. The sixth risk is subtler. The endpoint works "correctly," but a bot abuses it. Think of automated ticket buying, coupon redemption or bulk account creation, legitimate flows exploited at scale. In September 2022 an unauthenticated, internet-facing API at Optus exposed data on about 9.8 million customers; the company set aside 140 million Australian dollars for the fallout.

The APIs you can't see: the inventory problem

One of the most overlooked risks is ninth on the list, inventory management. Most organizations do not know exactly how many APIs they run. An old v1 version is still live, a test environment faces the internet, an endpoint a team shipped in a hurry is documented nowhere. You cannot protect an API you do not know exists, and attackers will find it before you do. So the first step is often not technical at all; it is taking inventory, listing every endpoint, version and environment.

What to actually do

API security comes down to a handful of principles. Verify authorization on the server, for every object, on every request; trust the session owner, not the ID the client sends. Build authentication on a standard protocol (OAuth 2.0, short-lived tokens). Constrain which properties can be read and written with an explicit schema. Put rate limits and quotas on every endpoint. Keep a current inventory of all your APIs and place them behind an API gateway. Finally, test the APIs themselves: web scanners cannot see logic flaws like BOLA, so you need penetration testing aimed at the API. A WAF or API gateway helps, but it does not fix the flaw in the logic.

In short, API security is not a subset of web security but a discipline of its own, and most breaches are not some exotic zero-day but a skipped authorization check. At Wedevit we review your APIs against the OWASP API Security Top 10, build the authorization and rate-limiting layer, and handle it together with your API-first integration design.