BOLA: The API Vulnerability Hiding in Plain Sight

Imagine logging into your online banking application and seeing your account balance, your transaction history, and your personal details. Everything is working exactly as expected. Now imagine changing a single number in the URL (the account ID) and suddenly seeing someone else's financial data. No hacking tools required. No sophisticated exploit chain. Just one digit.

This is not a hypothetical scenario. This is the exact type of vulnerability that led to T-Mobile exposing the data of 37 million customers in a breach disclosed in 2023, ultimately resulting in a class action settlement of $350 million.

It is the same class of flaw that allowed attackers to access the personal data and workout statistics of any Peloton user by simply swapping user IDs in API requests. And it is the same vulnerability pattern that, in Harbor (a widely used container registry), allowed a user with a basic Maintenance role to flip an entire private project to public and deploy unverified images by manipulating project metadata through an unauthorized API call.

The vulnerability at the heart of all these incidents has a name: Broken Object Level Authorization (BOLA). It is ranked #1 on the OWASP API Security Top 10 and is arguably the most prevalent, dangerous, and underestimated flaw in modern API security.

What is BOLA?

Broken Object Level Authorization is an authorization flaw where an API or web application fails to verify whether the user making a request has legitimate permission to access or modify the specific data object they are targeting. When a user requests a resource, such as a database record, a file, or a transaction, the application should check not only that the user is authenticated (that they are who they say they are), but also that they are authorized to interact with that particular object (that they have the right to see or change it).

When that authorization check is missing, weak, or inconsistently applied, an attacker can access other users' data simply by manipulating the object identifier in the request. Change an account number in a URL parameter. Swap a user ID in an API header. Modify a resource ID in a JSON payload. If the server does not validate object-level ownership on every request, it hands over data it should not.

It is worth distinguishing this from authentication. Authentication answers the question "who are you?", verifying identity through credentials, tokens, or multi-factor mechanisms. Authorization answers the question "what are you allowed to do?", determining which specific resources and actions are permitted for that identity. BOLA exploits a failure in the second check. The user is authenticated, logged in, and verified. They are simply accessing objects that do not belong to them, and the application does nothing to stop it.

BOLA and IDOR: Same flaw, different lens

If you have been in application security for any length of time, you will recognize that what OWASP calls BOLA sounds remarkably similar to another well-established vulnerability: Insecure Direct Object References (IDOR). This is a genuine point of contention in the cybersecurity community, and the naming overlap causes confusion that is worth addressing directly.

IDOR has its roots in the OWASP Web Application Security Top 10, where it appeared as early as 2007. The term describes a specific attack pattern: an application exposes a direct reference to an internal object, like a database key, a file name, or a sequential ID, and an attacker manipulates that reference to access something they should not. IDOR focused primarily on the mechanism of the exploit: the predictable, guessable, or enumerable identifier that the attacker tampers with.

BOLA, introduced through the OWASP API Security Top 10 in 2019, describes the same fundamental flaw, but from a broader perspective. Where IDOR zeroed in on the manipulable reference, BOLA reframes the issue as what it truly is: a broken authorization check at the object level.

The emphasis shifts from the attack vector ("the reference is insecure") to the root cause ("the authorization is broken"). BOLA also explicitly acknowledges that these flaws extend beyond simple URL tampering, as they can manifest in API request bodies, headers, nested object graphs, and across microservice boundaries where authorization logic may be inconsistently implemented.

In practice, the two terms describe the same family of vulnerabilities. Whether you call it IDOR or BOLA, the core problem is identical: an application trusts user-supplied identifiers without performing proper server-side authorization checks on the specific object being requested. The defenses are the same. The business impact is the same.

The nomenclature distinction matters, though, for two reasons:

• First, BOLA, as a framing, is more useful for modern API-driven architectures because it centers the conversation on authorization logic rather than a specific technical pattern. In a world of microservices, composable architectures, and increasingly complex API ecosystems, thinking about authorization holistically—across every endpoint, for every object—is more productive than thinking about whether a URL parameter is guessable.

• Second, because BOLA holds the #1 position on the OWASP API Security Top 10 and IDOR sits within the broader "Broken Access Control" category in the OWASP Web Application Top 10, using both terms accurately signals that you understand the full scope of the problem across both web and API contexts.

For the rest of this article, we will use BOLA as the primary term, but whenever you see BOLA, know that IDOR is part of the same story.

Why BOLA is uniquely dangerous

BOLA occupies a particularly treacherous position in the vulnerability landscape because it combines three characteristics that rarely appear together: it is easy to exploit, hard to detect, and devastating in impact.

Easy to exploit.

BOLA attacks do not require sophisticated tools, advanced technical knowledge, or complex exploit chains. An attacker can probe for these vulnerabilities with nothing more than a browser, a proxy tool, or a simple script. Change a parameter, observe the response. If data comes back that should not, the application is vulnerable. The barrier to entry is effectively zero, which means these flaws are exploitable by a far wider range of threat actors than most other vulnerability classes.

Hard to test. 

Traditional security testing methods struggle with BOLA because these are not technical flaws in the conventional sense; they are logic errors. A SQL injection leaves a detectable pattern in a query. A Cross-Site Scripting (XSS) vulnerability produces recognizable payloads. BOLA, by contrast, involves a perfectly well-formed, syntactically correct API request that simply returns data belonging to the wrong user. There is no malformed input, no suspicious payload, no anomalous pattern. The request looks legitimate. The response looks legitimate. The only thing that is wrong is that the person making the request should not have received that particular response.

Capable of bypassing modern defenses. 

Organizations with a mature security posture—Web Application Firewalls, API gateways, rate limiting, and authentication controls—can still be vulnerable to BOLA. These defenses are designed to catch unauthorized access, malformed requests, and known attack patterns. BOLA operates entirely in the bounds of normal, authenticated traffic. The user has valid credentials. The request format is correct. The API gateway sees an authenticated user making a legitimate-looking request. Nothing triggers an alert.

The business consequences are proportional to the severity. Data breaches exposing millions of records. Regulatory penalties. Class action lawsuits. Reputational damage that takes years to repair. When the attack is as simple as changing a number in a URL, the question is not whether attackers will try; it is whether your applications will stop them when they do.

What causes BOLA in the first place?

BOLA vulnerabilities are rarely the result of a single engineering mistake. They tend to emerge from a pattern of deeply flawed assumptions in how APIs are designed, built, and maintained.

Developers often over-rely on client-side checks and assume that users will not tamper with object IDs or tokens. This is a fundamentally wrong assumption, and the breach examples above prove it repeatedly. Beyond that, authorization logic is frequently implemented inconsistently across endpoints. When there is no centralized authorization framework—when each endpoint implements its own access control checks (or forgets to)—gaps are inevitable. An application might enforce authorization correctly on 99 out of 100 endpoints. The one that was missed becomes the entry point.

Testing practices compound the problem. Manual security testing and low-coverage automation rarely catch BOLA because these are not pattern-based vulnerabilities. You cannot find them by scanning for known signatures. Effective BOLA detection requires understanding business logic, data ownership, and the context of each request, capabilities that have historically been beyond the reach of automated tools.

And then there is the reality of modern software delivery: speed wins. Development teams are under constant pressure to ship APIs quickly to meet business demands, and authorization validation is frequently deprioritized in favor of feature delivery. The BOLA vulnerability that results from this tradeoff may remain undetected for months or years, until an attacker finds it.

The detection challenge

Identifying BOLA at scale is one of the hardest problems in application security, and it is worth understanding why.

The core challenge is that effective BOLA detection requires contextual understanding. The scanner needs to know not just that an API returns data, but whether that data should be accessible to the specific user making the request. Is this resource public or private? Is the requesting user the owner of this object? Should a user with this role be able to see this field? These are questions that depend entirely on the application's business logic and authorization rules, and they cannot be answered through pattern matching or signature-based detection.

Simple approaches to BOLA detection, like checking whether changing an ID returns different data, generate unacceptable levels of false positives. Many APIs intentionally serve public resources that are accessible to any authenticated user. A product catalog, a public profile, a shared document: these are supposed to be accessible across users. Flagging every instance where two users can access the same resource as a potential BOLA issue produces noise that drowns out genuine findings. AppSec teams already stretched thin cannot afford to investigate hundreds of false positives to find the handful of real authorization failures.

This is why some competitors who claim to offer BOLA detection deliver superficial results. Without the ability to understand the context of what is being accessed and whether it should be restricted, detection mechanisms remain naive, and the signal-to-noise ratio remains poor.

Why this matters more now than ever

The urgency around BOLA detection is not theoretical. Several converging forces are making this class of vulnerability more prevalent and more dangerous than at any point in the past.

1. The API attack surface is expanding. 

Modern applications are no longer monolithic codebases; they are composed of microservices communicating through APIs, with composable architectures replacing the old code monoliths. Every new microservice, every new API endpoint, every new integration is a potential BOLA exposure point. The sheer volume of API endpoints in a typical enterprise environment has grown by orders of magnitude, and authorization logic needs to be correctly implemented across all of them.

2. AI-generated code is accelerating the problem. 

76% of developers now use or plan to use AI coding tools (Stack Overflow, 2024), and a study of five major AI models found that at least 48% of their generated code snippets contained vulnerabilities. When code is generated at machine speed, the surface area for authorization errors multiplies accordingly. Developers working with AI coding assistants are shipping more code, faster, but the authorization logic in that code is only as good as the prompts and the review processes around it. In many cases, the generated code works functionally but skips the authorization checks that a security-conscious developer would have implemented.

3. AI agents are creating new exposure vectors. 

The rise of autonomous AI agents that interact with internal data and services through APIs adds another dimension to the problem. These agents communicate through the same API endpoints that serve human users, but they operate at machine speed and may chain multiple API calls in ways that human use patterns do not. If those API endpoints have BOLA vulnerabilities, an agent can be weaponized—or an attacker can exploit the same endpoints the agent uses—to exfiltrate data or modify resources at scale.

An Agent using a BOLA-compromised API is not a mere vulnerability: it’s an automatic data exfiltration machine.

Four of the top five entries on the OWASP API Security Top 10 are authorization and authentication issues. BOLA is not an isolated problem; it is the most visible symptom of a systemic challenge in how modern applications handle access control. Solving BOLA detection opens the door to addressing the broader family of authorization flaws that account for the majority of critical API security risks.

A new approach: AI-powered BOLA detection

The detection challenge that has made BOLA so persistent is, fundamentally, a contextual understanding problem. And this is precisely where recent advances in AI and Large Language Models (LLMs) are changing the equation.

The approach that Snyk API & Web has pioneered uses LLMs to analyze the context of API requests and authorization logic, going beyond traditional DAST techniques to classify content ownership and determine whether a response should be accessible to the requesting user. Rather than relying on simple ID-swapping heuristics that generate false positives, the AI-powered detection engine can reason about whether data is public or private, whether the requesting user is the legitimate owner, and whether the authorization boundary has genuinely been violated.

This is not about replacing the fundamentals of Dynamic Application Security Testing. DAST remains essential, testing applications from the outside in, probing the attack surface with payloads at scale, the way an attacker would. What AI brings to the table is the ability to layer contextual intelligence on top of that testing methodology, enabling the detection of vulnerabilities that are invisible to pattern-matching approaches. The result is BOLA detection with dramatically lower false positive rates, meaning AppSec teams receive actionable findings they can act on immediately, rather than noise they have to filter through.

And BOLA is just the beginning. The same AI-driven approach is being extended to address other authorization and authentication flaws in the OWASP API Security Top 10, because the technical challenge of understanding business logic context applies across the entire family of access control vulnerabilities. Solving BOLA detection creates the foundation for a fundamentally smarter approach to API security testing.

What security leaders should be asking

If you are responsible for your organization's application security program, BOLA deserves a place at the top of your risk assessment. Consider the following questions:

Do you have visibility into how authorization is implemented across your API endpoints, and is that implementation consistent? Inconsistency is where BOLA thrives. A centralized authorization framework, enforced across all services, is the most effective architectural defense.

Are your current testing tools actually capable of detecting BOLA, or do they claim to but deliver mostly false positives? Not all BOLA detection is created equal. Ask for proof of accuracy—false positive rates, detection methodology, and real-world results.

How are you accounting for the authorization implications of AI-generated code? If your developers are using AI coding assistants, the code they ship may be functionally correct but authorization-incomplete. Your testing methodology needs to catch what code review may miss.

And finally: are you testing from the outside in? Authorization flaws like BOLA are, by their nature, only fully visible when you test the application the way an attacker would—by probing running APIs and web applications with real requests, real payloads, and the perspective of someone trying to access what they should not. Static analysis can identify potential issues in code. Dynamic testing proves whether they are actually exploitable.

BOLA is the #1 risk on the OWASP API Security Top 10 for a reason. It is pervasive, hard to find, and when exploited, the consequences are measured in millions of dollars and millions of compromised records. The good news is that the detection problem is no longer unsolvable: AI-powered approaches are making it possible to find these flaws with the accuracy and contextual understanding that traditional tools never could. The question is whether your organization will find them before an attacker does.