In November 2018, KrebsOnSecurity disclosed that the United States Postal Service had left an API on its Informed Visibility platform wide open for over a year, letting any logged-in user query account details for the site's roughly 60 million registered users simply by changing a numeric ID in the request. No password guessing, no exploit chain — just an API endpoint that trusted the client to ask for its own data and never checked that it actually did. That flaw has a name: Broken Object Level Authorization, or BOLA, more commonly known by its older label, IDOR (Insecure Direct Object Reference). It has topped the OWASP API Security Top 10 as the number one risk since the list's inception in 2019, and it remains there in the 2023 revision. This post breaks down what BOLA actually is, why it keeps recurring in production APIs at well-resourced companies, and how Safeguard helps engineering teams catch it before attackers do.
What Is Broken Object Level Authorization?
BOLA is a failure to verify that the user making an API request is actually authorized to access the specific object they're requesting. Every API endpoint that accepts an identifier — /api/orders/4471, /api/users/8823/invoices, /api/documents/{id} — is a candidate for this bug if the backend checks "is this user logged in?" but never checks "does this user own object 4471?" An attacker who is authenticated as User A can simply increment, guess, or enumerate IDs and pull back User B's, User C's, or every user's data. This is distinct from Broken Function Level Authorization (BFLA), which is about access to entire endpoints or roles (API5:2023); BOLA is about access to individual records within an endpoint you're already allowed to call. The fix sounds trivial — add an ownership check on every object access — but in practice it has to happen consistently across hundreds or thousands of endpoints, often written by different teams over years, which is exactly why it keeps slipping through.
Why Has BOLA Topped the OWASP API Security Top 10 Since 2019?
BOLA has held the #1 spot on both the 2019 and 2023 editions of the OWASP API Security Top 10 because it is both extremely common and extremely easy to exploit once found. Unlike SQL injection or XSS, which usually require crafting a malicious payload, exploiting BOLA typically requires nothing more than changing a number or a UUID in a request the attacker is already authorized to send — no special tooling, no bypassing of input validation, no privilege escalation. Salt Security's State of API Security reports have repeatedly found that the large majority of organizations experienced an API security incident in the prior 12 months, and object-level authorization gaps are consistently cited as the leading root cause. Gartner's 2018 prediction that "by 2022, API abuses will move from an infrequent to the most frequent attack vector" has effectively played out, and BOLA is the archetype of that abuse: low technical bar, high blast radius, and invisible to traditional perimeter defenses because the traffic looks like a normal, authenticated user doing normal things.
Which Real-World Breaches Were Actually BOLA?
Several of the highest-profile API breaches of the last five years trace back to exactly this flaw. The USPS Informed Visibility exposure (disclosed November 2018, ~60 million accounts) is the textbook case. In May 2021, security researchers found that Peloton's API let any authenticated user pull private account data — including age, gender, weight, and location — for any of its roughly 3 million riders by requesting user IDs that weren't their own, with no ownership check on the response. Also in 2021, Experian's partner lookup API allowed anyone who could guess a person's name, address, and ZIP code to retrieve their credit score band through a third-party lender's website, because the endpoint returned data for whatever identity was supplied rather than verifying the requester's relationship to it. Parler's January 2021 breach involved scraping millions of posts, videos, and location-tagged content by iterating sequential, unauthenticated post IDs. Each of these had nothing to do with stolen credentials or zero-day exploits — they were APIs that answered questions they should have refused to answer.
Why Do Traditional Security Tools Miss BOLA?
Traditional security tools miss BOLA because it isn't a signature, a known-bad payload, or a malformed request — it's a business logic gap that only shows up when you understand what a specific request should be allowed to return for a specific user. A web application firewall sees a well-formed, authenticated GET request to /api/invoices/9931 and has no way to know whether the caller is entitled to invoice 9931 specifically. Static analysis tools (SAST) can flag missing authorization checks only if the pattern is textually recognizable, but authorization logic is frequently scattered across middleware, ORM query filters, and service-layer code that a scanner can't correlate. Dynamic scanners (DAST) typically test one account at a time and never attempt the specific two-account, cross-tenant comparison that BOLA testing requires: does Account A's token retrieve Account B's object? This is also why BOLA thrives in the exact places modern engineering teams generate the most surface area fastest — microservices, mobile-app backends, and partner/GraphQL APIs added in the last two or three sprints, none of which get the same scrutiny as the original monolith.
How Much Does a BOLA Breach Actually Cost?
A BOLA-driven breach carries the same downstream costs as any large-scale data exposure, and those costs have been climbing steadily — IBM's Cost of a Data Breach Report put the global average at $4.45 million in 2023 and $4.88 million in 2024, with breaches involving customer PII and those that go undetected for longer both trending well above average. T-Mobile's API-driven breach, disclosed in January 2023, let an attacker pull data on 37 million customer accounts over roughly six weeks starting in late November 2022 before it was caught — the cost wasn't a single exploit, it was six weeks of an API quietly answering questions it should have refused, compounded by breach notification, regulatory scrutiny, and the customer trust that doesn't come back cheaply. Because BOLA exploitation looks like normal authenticated traffic, the average time to detect these incidents tends to run longer than for exploits that trip an IDS or WAF signature, which directly inflates both the scope of the exposure and the eventual cost.
Where Should Teams Start Fixing This?
Teams should start by inventorying every endpoint that accepts an object identifier and confirming each one enforces ownership or tenancy checks server-side, not just authentication. A useful rule of thumb: if an endpoint's response changes based on which ID is passed in, that endpoint needs an explicit "does the authenticated principal own or have a grant on this object" check, evaluated on every request rather than cached or assumed from a prior call. This has to be enforced centrally — in a shared authorization layer or middleware — rather than left to individual engineers to remember on each new route, because the USPS, Peloton, and Parler incidents all involved teams that had authorization logic elsewhere in the app; they just didn't apply it consistently to the endpoint that got exploited. Non-sequential, non-enumerable identifiers (UUIDs instead of auto-incrementing integers) reduce the ease of guessing but do not fix the underlying authorization gap and should never be treated as a substitute for an ownership check.
How Safeguard Helps
Safeguard is built to catch exactly this class of gap before it ships. Because BOLA is a logic flaw rather than a known signature, catching it requires visibility into the full software supply chain — the API contracts, the dependency and service graph, and the actual authorization code paths that connect a request to the data it returns — not just a point-in-time pen test. Safeguard's continuous scanning maps every API endpoint your services expose, flags identifier-accepting routes that lack a corresponding, consistently-applied ownership or tenancy check, and surfaces newly introduced endpoints from feature branches and microservices before they reach production, so BOLA gaps get caught in code review rather than in a breach disclosure. For teams managing sprawling API surfaces across multiple repos and services, Safeguard correlates authorization logic across your dependency and service graph so a gap in one shared library or middleware doesn't silently propagate to every endpoint that imports it. The goal is straightforward: turn "we hope every engineer remembered the ownership check" into a continuously verified guarantee, so the next BOLA headline isn't about your API.