CyphrQ
Menu

API Security Breaches: How Data Leaks Through APIs and How to Stop It

How attackers pull data out through APIs, mapped to the OWASP API Security Top 10 2023, two documented cases, and the controls that work.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

Many API security breaches don't involve breaking encryption or planting malware. The attacker asks the API for data, and the API hands it over because it never checked whether this caller should see that record, or how many records one caller should be allowed to pull. The fixes are an inventory of every API you run, an authorisation check on every object, limits on volume, and tests that try to fetch someone else's data.

This post explains how that happens in plain terms, walks through two cases documented in a US securities filing and an EU regulator's decision, and ends with the controls and the tests that catch the problem before an attacker does.

What is an API, and why do API security breaches expose so much data?

An API (application programming interface) is the way one piece of software asks another for data or actions. When your banking app shows your balance, it is calling an API. When a partner system checks a customer's order, it is calling an API.

APIs are built to return data quickly to other programs. That makes them efficient, and it makes a flaw efficient too. A person clicking through a website sees one record at a time. A script calling a flawed API can collect millions of records, each request looking much like a normal one.

Two features make API leaks hard to spot:

  • Each request can look legitimate. The caller may be authenticated, using a real token, asking for a real record. The only problem is that the record belongs to someone else.
  • Volume is the attack. One request for one customer is normal. Ten thousand requests walking through customer numbers in order is a breach in progress.

How do attackers get data out of an API?

The OWASP API Security Top 10 2023 is the standard reference list of API risks. OWASP is a non-profit community that publishes open security guidance. These are the entries most closely tied to data leaks:

OWASP 2023 entry What goes wrong, in plain terms
API1:2023 Broken Object Level Authorization (BOLA) The API accepts a record ID from the caller and returns that record without checking the caller is allowed to see it. Change the ID, get another person's data.
API2:2023 Broken Authentication Flaws in how the API confirms who is calling let an attacker take over tokens or impersonate users.
API3:2023 Broken Object Property Level Authorization The API returns, or accepts changes to, fields the caller should not see or edit. This merges two 2019 entries: excessive data exposure and mass assignment.
API4:2023 Unrestricted Resource Consumption No limits on how much a caller can request, which allows bulk extraction as well as service outages and runaway costs.
API6:2023 Unrestricted Access to Sensitive Business Flows A legitimate feature, such as a lookup or a contact importer, can be automated at a scale that harms the business. OWASP notes this is often not a coding bug.
API9:2023 Improper Inventory Management Old versions, test endpoints and forgotten hosts stay online without the protections of the main API.

If you remember one entry, make it API1. Broken object level authorization means the API checks that you are logged in, but not that the record you asked for is yours.

A note on terms: older articles talk about "excessive data exposure", the 2019 name for an API returning more fields than the screen shows and trusting the app to hide them. In the 2023 list that problem lives inside API3.

What happened in the T-Mobile API breach of 2023?

T-Mobile US described the incident in a Form 8-K filed with the US Securities and Exchange Commission, dated 19 January 2023.

  • What was found. On 5 January 2023 the company identified that "a bad actor was obtaining data through a single Application Programming Interface" without authorisation.
  • How long. It believed the data was first retrieved through that API starting on or around 25 November 2022, about six weeks before discovery.
  • How many. Its preliminary result was data for "approximately 37 million current postpaid and prepaid customer accounts", though many did not include the full data set.
  • What data. Name, billing address, email, phone number, date of birth, T-Mobile account number, and information such as the number of lines and plan features.
  • What was not exposed. The filing says the API did not provide access to payment card information, Social Security numbers or tax IDs, driver's licence or other government ID numbers, passwords or PINs, or other financial account information.
  • Response. T-Mobile said it traced the source and stopped the activity within a day of learning of it, and that it "may incur significant expenses" in connection with the incident.

The filing does not say which design flaw allowed the access, so this post does not guess at an OWASP category. The lesson that is on the record is the timeline: an API was returning customer data to someone without authorisation for weeks before it was noticed. In my view, volume monitoring on that one API could have been an early signal.

What did Ireland's regulator find in the Facebook scraping case?

On 25 November 2022 Ireland's Data Protection Commission (DPC) adopted a decision against Meta Platforms Ireland and fined it €265 million, announced in a DPC press release on 28 November 2022.

  • What it examined. Three features: Facebook Search, Facebook Messenger Contact Importer and Instagram Contact Importer, for the period 25 May 2018 to September 2019.
  • What it found. Infringements of Articles 25(1) and 25(2) of the GDPR: data protection by design and by default.
  • What it ordered. A reprimand, an order to bring processing into compliance, and the fines.

The DPC does not use OWASP categories. My reading is that, in OWASP terms, this matches API6: the regulator's findings were about how the features were designed to protect personal data (by design and by default), not about a coding error. For any lookup feature that returns personal data, the design questions are "what stops one caller from running this a million times?" and "what is the least data this feature needs to return?"

For an Australian case where both the privacy regulator and the communications regulator have gone to court, see the Optus case file. That post covers the legal claims; this one does not repeat them.

Which API security controls stop data leaks?

No single product fixes API security. These five controls, done together, are what I recommend against the leak patterns above.

  1. Know every API you run. Keep an inventory of every endpoint, version and host, including test, partner and mobile backends. Turn off old versions when you release new ones. You cannot protect an API you have forgotten.
  2. Check authorisation on every object, every time. For every request that names a record, the server checks that this caller may access this record. Do it in shared server-side code, not in each endpoint, and never rely on the app to hide data.
  3. Return only the fields the caller needs. Define response shapes explicitly. Do not return a full database object and let the client choose what to display.
  4. Limit volume per caller and per object type. Rate limits per token, per account and per IP, plus limits on how many distinct records one caller can read in a time window. Alert when a caller crosses them.
  5. Test like an attacker, safely. Before every release, test with two users: can user A fetch user B's records by changing an ID? Add the test to your automated build so it runs every time.

Going deeper: for security and IT teams

Threat model. The attacker usually has a valid account, a leaked API key, or nothing at all for an unauthenticated endpoint. They need the API's URL patterns, which are visible in mobile app traffic or public documentation. They get bulk records at machine speed, through requests that pass authentication and look normal one by one. The defender's disadvantage is that the web application firewall sees well-formed requests, so the controls must sit in the application's authorisation logic and in behavioural monitoring.

Object-level authorisation (API1). Enforce it in a central policy layer that every handler calls, taking the authenticated principal from the validated token, never from a request parameter. Deny by default when the ownership lookup fails. Random identifiers (UUIDs) make enumeration harder, but an ID that is hard to guess is still not an authorisation check; IDs leak through logs, links and shared screenshots. Write negative tests for every endpoint that takes an ID: same tenant different user, different tenant, unauthenticated, and a deleted or archived record.

Property-level authorisation (API3). Use explicit allow-lists for response fields per role, and separate input schemas that reject unexpected properties, which blocks mass assignment (a caller setting role or isAdmin in a request body). Validate responses against the OpenAPI schema in tests, so a developer adding a field to a database object does not silently expose it.

Consumption and business flows (API4, API6). Set limits at several levels: requests per second per token, distinct object IDs read per account per hour, and maximum page size. For lookup-style features (search by phone number, contact import), add friction proportionate to the data returned, cap results, and return less data to unverified accounts. Log and alert on sequential or high-cardinality ID access from one principal; that pattern is enumeration.

Inventory (API9). Build the inventory from traffic, not only from documentation: API gateway logs, load balancer and DNS records, and cloud asset inventories. Tag each API with owner, data classification, authentication method and whether it is internet-facing. Deprecated versions get a shutdown date, then a block.

Standards to map to. NIST's SP 800-228 Guidelines for API Protection for Cloud-Native Systems, update 1 (updated 13 March 2026, superseding the June 2025 original) organises controls into pre-runtime protections, applied during development and before deployment, and runtime protections. The update adds an appendix listing API risks by category and one listing recommended controls by API lifecycle stage. Use it with the OWASP list: OWASP names the failure, NIST gives the control structure.

Detection and evidence. At minimum, log for every API call: authenticated principal, client ID or key, endpoint and method, object IDs requested, response status, response size and source IP. Alerts worth having: - One principal reading far more distinct object IDs than its baseline. - A spike in 403 or 404 responses from one caller, a sign of ID guessing. - Traffic to an API version marked deprecated. - Response sizes well above normal for an endpoint.

Testing that the controls work. Include BOLA and BOPLA test cases in every penetration test scope, with at least two test accounts per role and tenant. Run authorisation tests in the build pipeline against a staging environment seeded with synthetic data. Never test with real customer records.

Questions for your team and suppliers. - Can we produce a list of every internet-facing API, with an owner, today? - Where in the code is object-level authorisation enforced, and is it shared or per endpoint? - What is the most records one account could read from our customer API in an hour? - Which partner integrations consume our APIs, and what scopes do their keys have? - If one API leaked data for six weeks, which log would show it, and who would read it?

If a leak does happen, the regulatory clock starts when you become aware. The breach notification deadlines guide lists the timelines by country.

An API security checklist for product and engineering leaders

  1. Name an owner for the API inventory and review it every quarter.
  2. Make object-level authorisation a shared library or gateway policy, not a per-endpoint habit.
  3. Ban returning full database objects in API responses.
  4. Set per-account rate limits and distinct-record limits on every API that returns personal data.
  5. Add a two-user authorisation test to the release pipeline.
  6. Shut down deprecated API versions on a published date.
  7. Log enough to answer "who read which records" for at least as long as your notification obligations need.
  8. Include APIs, mobile backends and partner endpoints in every penetration test.

Key takeaways

  • API breaches usually happen because the API returns data without checking that the caller may see that record, or without limiting how many records one caller can take.
  • The OWASP API Security Top 10 2023 names the main failures: broken object level authorization (API1), broken authentication (API2), broken object property level authorization (API3), and unrestricted consumption and business flows (API4, API6).
  • T-Mobile's January 2023 SEC filing describes a single API used without authorisation from around 25 November 2022, affecting about 37 million accounts.
  • Ireland's DPC fined Meta €265 million in November 2022 under GDPR Article 25 for how lookup and contact-import features protected personal data.
  • Inventory, per-object authorisation, minimal responses, volume limits and two-user tests are the controls I recommend against these leak patterns.

Sources