The ID That Costs Millions: Why API Authorization Failures Keep Winning

There is a specific silence that falls over a security team the moment they realize the breach wasn't sophisticated. No zero-day. No nation-state tooling. No polymorphic malware that burned through your EDR like tissue paper. Just someone — maybe a curious teenager with a browser and a free afternoon — who changed a number in a URL.

I've watched that silence happen in person. Late 2023, a mid-size fintech in Lagos whose name you'd recognize if I printed it. Their API had been live for eleven months. Their security budget wasn't small. Their CTO had a CompTIA Security+ cert framed above his monitor. And yet their entire customer transaction history — account numbers, transfer amounts, recipient details — was sitting there, accessible to anyone who'd bothered to increment an integer past their own user ID.

They called it a "configuration oversight." I call it the industry's most durable, most avoidable, and frankly most embarrassing class of vulnerability. OWASP does too. Broken Object Level Authorization — BOLA, or IDOR if you learned it before the acronym refresh — has anchored the top of the OWASP API Security Top 10 since the list first dropped in 2019. It hasn't moved. We haven't fixed it.

An Authentication Obsession That Leaves the Door Open

Here's the thing that took me years of covering breaches to fully internalize: the security industry is monomaniacally focused on who you are, and pathologically indifferent to what you're allowed to touch.

Password policies, MFA mandates, OAuth flows, FIDO2 passkeys — billions of dollars and an entire professional ecosystem devoted to the question of identity verification. And rightly so. But authentication is the front door. Authorization is every door inside the house. Most developers lock the front door with a deadbolt and leave every interior room hanging open.

A valid JWT token — the kind modern APIs hand out like business cards — proves you are who you say you are. Full stop. It does not, in the absence of explicit ownership checks, prove you have any right to the resource at the end of the URL you're requesting. An attacker who logs in as themselves, captures a request to /invoices/7841, and then manually changes that ID to /invoices/7842? They're still presenting a perfectly valid token. The server, absent any code that asks "does this user own invoice 7842?", has no reason to object.

This isn't an obscure edge case. It's the default behavior of most database query patterns. Developers write SELECT * FROM orders WHERE id = ? and bind the ID from the URL path. The user's identity is verified at the route guard level. Nobody adds the AND owner_id = ? clause because nobody's thinking about the attack surface at query-construction time. They're thinking about shipping.

What the Exploitation Actually Looks Like

I want to be precise here, because the trade press often describes BOLA in the abstract and leaves practitioners without a visceral sense of what it means in practice. Let me walk through what a pentester actually does — and how fast it goes.

You log in. You grab your session token. You make one legitimate request and note the object ID that comes back. Then you write a loop. Twenty lines of Python, maybe thirty if you want clean output files. You iterate through a range of IDs — say, a thousand on either side of your own — and you log every response that returns a 200 status with a non-empty body.

That's it. That's the "attack." There's no obfuscation, no encoding trickery, no waiting for a rate-limit window. On a poorly protected API, a single laptop running that script for ten minutes can harvest tens of thousands of records. I've seen pentesters demonstrate this in client presentations and watch the color drain from product managers' faces in real time.

The scarier version — and this is what the Uber incident in 2019 illustrated so cleanly — is when the object IDs are UUIDs instead of sequential integers. Engineers sometimes believe UUID-based IDs provide security through obscurity. They don't. Once you have one UUID from your own account, an attacker who can find another ID through any secondary channel (a shared link, a notification email, a public profile URL) can immediately test whether the API enforces ownership. UUID randomness buys you exactly nothing if the authorization check isn't there.

The Detection Gap

What frustrates me most about the industry's response to BOLA is the persistent belief that existing automated tooling will catch it. It won't. Not reliably. Not by default.

SAST tools scan source code for patterns. BOLA is a logic flaw. There's no malicious syntax to detect. The query looks correct. The route handler looks correct. The token validation looks correct. The problem is what's absent, not what's present — and static analysis is poorly suited to reasoning about absent logic.

Dynamic scanners — your DAST tools, your API fuzzers — face a different problem. They send requests and evaluate responses. But a BOLA-vulnerable endpoint returns 200 OK with valid JSON. To a scanner without context about which user should own which resource, that looks like correct behavior. Some next-generation tools are beginning to address this with correlation logic, and vendors like Traceable and Salt Security have made credible inroads. But as of early 2026, most automated pipelines would pass a catastrophically BOLA-vulnerable API with flying colors.

The uncomfortable conclusion: the only reliable detection is manual testing or custom-written negative tests that encode ownership expectations explicitly.

The Fix Is Not Complicated — Which Is Why It's Inexcusable

The remediation for BOLA is surgically simple. When a user requests an object by ID, your database query must bind both the object ID and the requesting user's identity — pulled from the verified token, not from user-controlled input:

SELECT * FROM orders WHERE id = $1 AND owner_id = $2;

If that query returns zero rows, you return a 404 or 403. Not the object. Not a helpful error explaining why. Nothing that confirms the object exists.

The catch is that this pattern has to be applied to every endpoint that accepts an object identifier. One missed endpoint — one endpoint where a junior developer wrote the query without the ownership clause, or where a legacy route never got the retrofit — is all an attacker needs. A breach doesn't require a systemic failure. It requires one gap.

This is why the fix has to live in process, not just in individual code review. Code review catches what reviewers know to look for. Automated ownership-check tests in a CI pipeline catch it every time, on every PR, regardless of who wrote the code or whether the reviewer was tired that afternoon.

What CI-Level Testing Actually Changes

The argument for baking BOLA tests into continuous integration isn't just defensive — it's operational. Consider the alternative: you discover a BOLA vulnerability during a quarterly pentest. You remediate. Six months later, a new engineer adds a feature without the ownership clause. Your next quarterly pentest catches it — after six months of exposure.

A CI test rewrites that timeline entirely. You write the test once: create two test accounts, have one request a resource owned by the other, assert a 403 response. The test runs on every pull request. If anyone introduces a BOLA vulnerability — at any point, in any feature — the build fails. The vulnerability never reaches production. The window of exposure is measured in minutes, not months.

That's not a theoretical improvement. That's the difference between a data breach and a non-event. Engineers who treat authorization tests as first-class citizens in the test suite — on par with unit tests for business logic — are doing something that a majority of the industry still doesn't do consistently.

The Cost of Getting It Wrong

I'm careful about citing breach figures because the industry has a long tradition of laundering dubious estimates into authoritative-sounding statistics. But some numbers are hard to argue with.

The Peloton exposure in 2022 — where any authenticated user could query any other user's profile data, including age, weight, workout history, and heart rate — affected millions of accounts before it was patched. Optus, the Australian telecoms giant, suffered a breach in late 2022 attributed in part to an exposed API endpoint that lacked adequate access controls; the regulatory and legal fallout has stretched into 2025, with fines and class-action proceedings still grinding forward. The T-Mobile API breach in January 2023 exposed the personal data of approximately 37 million customers through what investigators described as an improperly secured API endpoint — one that had apparently been running undetected since November 2022.

In each case: not a sophisticated attack. A door left open.

GDPR Article 83 fines for data protection failures can reach four percent of global annual turnover. For a company with a billion dollars in revenue, that's forty million dollars — for a missing AND owner_id = ? clause. The math is not subtle.

A Cultural Problem Masquerading as a Technical One

I've spent enough time in engineering organizations to know that BOLA persists not because developers lack knowledge but because authorization is treated as someone else's problem. Authentication is a platform concern, handled by the identity team. Authorization, in too many shops, is implicitly assumed to be handled by authentication — a category error that nobody explicitly corrects because nobody explicitly owns it.

The fix isn't just technical. It's organizational. Somebody has to own the answer to "does our authorization model enforce ownership at the object level, on every endpoint, verified on every deploy?" That responsibility has to be named, staffed, and tested. Not assumed.

Until the industry treats a missing ownership check with the same severity as a SQL injection — and in practice, the blast radius is comparable — BOLA will continue to top the list. Not because it's hard to fix, but because it's easy to overlook. And in security, what's easy to overlook is exactly what ends up in the breach notification letter.

The author has covered API security, cloud infrastructure vulnerabilities, and enterprise risk for fifteen years, and has consulted with security teams across financial services, healthcare, and critical infrastructure sectors.