Broken Object Level Authorization (BOLA) is a vulnerability where an application checks that a user is authenticated but fails to check whether that user is authorized to access the specific object they're requesting. An attacker simply changes an ID in an API call — an order number, invoice ID, or account number — and the server hands back someone else's data. OWASP ranked it API1:2023, the single most common flaw in its 2023 API Security Top 10, and CWE classifies it as CWE-639 (Authorization Bypass Through User-Controlled Key). It's the modern, API-first evolution of the older IDOR (Insecure Direct Object Reference) bug class, and it's shown up in breaches at T-Mobile, USPS, and Peloton. Because BOLA lives in application logic rather than a missing patch, scanners that only check for known CVEs routinely miss it — which is exactly why it keeps landing at the top of the list.
What is BOLA and how is it different from IDOR?
BOLA is the API-era name for the same core flaw IDOR described for over a decade: an app trusts a client-supplied identifier without verifying the requester owns that resource. The terms are close cousins, but OWASP introduced "BOLA" in the 2019 API Security Top 10 (and kept it as API1 in the 2023 revision) to separate API-specific object authorization failures from broader web IDOR issues like exposed file paths or database keys in HTML forms. In practice, BOLA almost always involves a REST or GraphQL endpoint where an object ID — /api/v1/accounts/{id} or a GraphQL node ID — sits in the URL, query string, or request body, and the backend never re-checks ownership against the authenticated session. If your API returns a 200 with someone else's record instead of a 403, you have BOLA.
Why is BOLA the number one risk in the OWASP API Security Top 10?
BOLA holds the API1:2023 slot because it's both the easiest vulnerability class to exploit and one of the hardest to catch with automated scanning. Exploiting it requires no special tooling — an attacker with a valid low-privilege account can find it by incrementing an integer ID or swapping a UUID captured from their own traffic in Burp Suite or Postman. Detecting it is hard because the request is syntactically valid, hits a real endpoint, and returns a normal-looking 200 response; there's no malformed payload, injection string, or error trace for a WAF or traditional DAST scanner to flag. Gartner and OWASP have both noted that API traffic now outpaces web UI traffic at most enterprises, and every one of those endpoints is a candidate for a missed ownership check.
How does a BOLA attack actually work?
A BOLA attack works by an authenticated user tampering with an object identifier in a request to reach data or actions that belong to someone else. Take a billing endpoint: a legitimate user logs in and retrieves their invoice at GET /api/v1/customers/44210/invoices/98341. If the backend authenticates the JWT but never confirms invoice 98341 actually belongs to customer 44210, the same user can request GET /api/v1/customers/44210/invoices/98342 and read a stranger's invoice — full name, billing address, amount charged. Swap the verb to PUT or DELETE against the same unguarded object, and the attacker can modify or cancel someone else's record, not just view it. Because IDs are frequently sequential integers or predictable UUIDs derived from timestamps, an attacker can script the increment and exfiltrate thousands of records in minutes with a simple loop, no exploit development required.
What real-world breaches were caused by BOLA?
BOLA has caused some of the largest API breaches on record, and the pattern repeats across industries. In November 2018, the U.S. Postal Service left an authentication API exposed that let any logged-in user query and modify account details — names, emails, physical addresses — for roughly 60 million Informed Visibility users, because the API validated login but not per-record ownership (reported by KrebsOnSecurity). In May 2021, researchers at Pen Test Partners found a Peloton API endpoint that returned any user's private profile data — age, weight, gender, city, workout stats — to any other logged-in user, regardless of that user's privacy settings, because the endpoint checked for a valid session but not for a relationship between the requester and the requested profile. In January 2023, T-Mobile disclosed that an attacker abused a single exposed API for roughly six weeks starting in November 2022 to pull data — names, billing addresses, phone numbers, dates of birth — on 37 million customer accounts, its eighth breach disclosure in five years. None of these required malware, phishing, or a zero-day; each was a valid API call missing one ownership check.
Is BOLA the same thing as BFLA?
No — BOLA and BFLA are related but distinct entries on the OWASP API Security Top 10, and conflating them leads teams to test for one while missing the other. BOLA (API1:2023) is about object access: can user A retrieve or modify a specific record — invoice 98342, account 44210 — that belongs to user B? BFLA, Broken Function Level Authorization (API5:2023), is about function access: can a regular user call an administrative operation, such as POST /api/v1/admin/users/{id}/promote or a bulk-delete endpoint, that should be restricted to a higher-privilege role? A single API can suffer from both: a standard user might be blocked from the admin dashboard's UI (correct function-level control) but still able to hit the underlying admin API endpoint directly with a swapped object ID (a combined BFLA-then-BOLA chain). Testing both requires enumerating roles as well as objects — verifying not just "does this user own this record" but "should this user's role be calling this endpoint at all."
How can security teams detect and prevent BOLA before attackers find it?
Teams catch BOLA by combining an accurate API inventory with authorization tests that check object ownership per role and per record, not just per endpoint. Start with discovery: you cannot test authorization on APIs your security team doesn't know exist, and shadow or deprecated API versions are a common source of unpatched BOLA. From there, testing has to move past "does this endpoint require a token" to "does user A's token grant access to user B's object" — a distinction static scanners and most DAST tools skip because it requires understanding data ownership, not just HTTP responses. OWASP's own guidance recommends enforcing authorization checks in a centralized policy layer (rather than scattered per-controller logic), using non-guessable, random object identifiers instead of sequential integers, and validating both the user's authentication and their specific relationship to the requested object on every single request, including nested and bulk endpoints. Manual penetration testing with multiple test accounts of different privilege levels remains one of the most reliable ways to surface BOLA, since the flaw is defined by business logic rather than syntax.
How Safeguard Helps
Safeguard closes the gap that lets BOLA slip through traditional scanning by combining reachability analysis with API-aware risk context, so teams aren't stuck triaging every endpoint that merely exists. Griffin AI, Safeguard's AI agent, correlates API inventory, code paths, and authorization logic to flag object-level access checks that are missing or inconsistently enforced, then ranks them by actual exploitability instead of raw finding count. Safeguard's SBOM generation and ingest pipeline maps which services and libraries handle object-level authorization so a gap in one shared auth module doesn't get evaluated endpoint-by-endpoint in isolation. When a fix is straightforward — adding an ownership check before a data access call — Safeguard can open an auto-fix pull request with the corrected authorization logic, so engineering teams remediate BOLA findings in a code review instead of a spreadsheet.