What Is Broken Object Level Authorization (BOLA)?
Written By
Sarwat Iftikhar
Broken Object Level Authorization has held the top spot on the OWASP API Security Top 10 for two consecutive editions. It is not a complex exploit. An attacker changes a single value in an API request (an ID, a UUID, a slug) and the server returns data that belongs to a different user. No privilege escalation, no token forgery, no lateral movement. Just a different number.
That simplicity is what makes BOLA so dangerous. The vulnerability is architectural rather than technical. It lives in the space between what an API endpoint does and what it should verify before doing it.
This post covers what BOLA is, how an attack works in practice, what types of APIs are most exposed, how it differs from related vulnerability classes, and what remediation actually requires. For development teams building APIs and security teams evaluating them, understanding why BOLA is so persistent matters as much as knowing what it is.
Key Takeaways
- BOLA occurs when an API uses a client-supplied identifier to retrieve data without verifying the requesting user owns that object
- It is the most prevalent API vulnerability and the hardest to detect with automated scanners because requests look structurally valid
- REST APIs, GraphQL APIs, and internal microservice APIs are all affected
- Remediation requires server-side ownership checks on every object-level operation, not just authentication
- BOLA and IDOR describe the same class of flaw; BOLA is the API-specific framing used by OWASP
What Makes an API Endpoint Vulnerable to BOLA?
Every API that retrieves, modifies, or deletes a specific resource using an identifier supplied in the request is a candidate for BOLA. The vulnerability is not in the identifier itself: it is in what the server does with it.
A well-designed endpoint receives an object ID, confirms the authenticated user is the owner of that object (or has explicit permission to access it), and then serves the data. A BOLA-vulnerable endpoint skips that ownership check. It authenticates the user, trusts the ID in the request, queries the database, and returns whatever it finds.
Authentication is not authorization. These two controls are frequently confused, and that confusion is the root cause of most BOLA findings. Authentication confirms who the user is. Authorization, specifically object-level authorization, confirms whether that user is allowed to interact with the specific object they are requesting. Web application security failures most commonly occur when developers implement authentication correctly and skip object-level authorization entirely.
Predictable or enumerable identifiers amplify the risk. Sequential integers (/api/orders/1001, /api/orders/1002) are the most obvious example, but UUIDs do not solve the problem. If the server does not verify ownership, a UUID an attacker obtained through any other means (a shared link, a leaked log, a different vulnerable endpoint) is sufficient to access the associated object.
Trusted client-supplied IDs are the direct cause. When Bugstrix engineers review API implementations, the consistent finding is that developers assume the client will only send IDs belonging to the authenticated user. That assumption is the vulnerability. Access control built on trust rather than verification does not hold under adversarial conditions.
Proper identity and access management design requires that every access decision be made on the server, using the authenticated identity from the session or token, not the identifier supplied in the request.
How Does a BOLA Attack Work?
A BOLA attack requires two things: an authenticated session and knowledge that an object ID exists. The mechanics are straightforward.
An attacker authenticates to an application as a legitimate user. While using the application normally, they observe the structure of API requests through browser developer tools or a proxy. They identify an endpoint that accepts an object ID as a parameter: GET /api/v1/invoices/4821. They increment or manipulate that ID to GET /api/v1/invoices/4820, and the server responds with another user’s invoice.
The request is structurally identical to a legitimate one. The attacker is authenticated. The token is valid. The only difference is the ID belongs to a different user’s object. Without a server-side ownership check, the server has no basis to reject the request.
Bugstrix assessments consistently surface BOLA at endpoints that handle the most sensitive data: account details, financial records, document stores, healthcare data, and administrative configurations. The business impact scales directly with how sensitive the exposed objects are.
What Types of APIs Are Most Exposed?
BOLA is not limited to public-facing REST endpoints. The vulnerability appears wherever an API accepts an identifier and retrieves an associated object without verifying ownership.
REST APIs are the most frequently affected because REST design naturally exposes resource identifiers in URLs. Every endpoint following a /resource/{id} pattern is a candidate. The more granular the API, the more object-level operations exist, and the larger the potential attack surface.
GraphQL APIs present a different but equally significant exposure. Queries that accept an ID argument and return a specific node are structurally identical to REST endpoints from a BOLA perspective. The flexibility of GraphQL, the ability to request arbitrary fields, means a successful BOLA exploit may expose more data in a single request than a REST equivalent.
Internal microservice APIs are frequently overlooked. Teams building internal APIs often skip authorization controls on the assumption that internal traffic is trusted. When another service or a compromised internal client sends a crafted request, that assumption fails. API security testing scope should explicitly include internal and service-to-service APIs, not just external-facing endpoints.
Batch and bulk endpoints compound the issue. An endpoint that accepts a list of IDs and returns all associated objects may expose many records in a single request. If the server validates ownership for none of the IDs in the list, a short enumeration loop yields mass data exposure.
How Is BOLA Different From IDOR and Access Control Failures?
BOLA and IDOR describe the same vulnerability class. IDOR (Insecure Direct Object Reference) is the older, broader term covering any case where an attacker manipulates a reference (a file path, a URL parameter, a cookie value) to access unauthorized resources. BOLA is OWASP’s API-specific framing of the same flaw, scoped to object identifiers in API requests. The underlying mechanism is identical: the server accepts a user-supplied reference to an object without verifying the requester is authorized to access it.
BOLA is a subset of Broken Access Control (BAC). BAC (OWASP Web Application Security Top 10 number one) is the parent category covering all forms of authorization failure: horizontal privilege escalation, vertical privilege escalation, function-level access control failures, and insecure direct object references. BOLA is specifically horizontal: an authenticated user accessing another user’s data at the same privilege level.
The practical distinction matters when scoping a remediation. A web application security review that surfaces BOLA findings should trigger a broader access control audit. Where object-level authorization is missing, function-level and field-level authorization controls are often underdeveloped as well.
Vertical privilege escalation is a different failure mode. A low-privilege user accessing an admin endpoint is distinct from a regular user accessing another regular user’s data. Both are access control failures. BOLA is specifically about horizontal, peer-to-peer data access: the attacker and the victim operate at the same authorization tier.
How Is BOLA Found During Security Testing?
BOLA does not surface through automated vulnerability scanning. A scanner that sends a request to /api/invoices/4821 sees a valid authenticated request return a 200. It has no basis to judge whether that invoice belongs to the authenticated user. Finding BOLA requires a tester who understands application context and tests business logic, not just HTTP responses.
Penetration testing is the primary detection method. Bugstrix penetration testing services for API-heavy applications structure BOLA testing around two-account cross-user verification: creating two test accounts, performing operations as account A to capture object IDs, and replaying those requests authenticated as account B. Any successful cross-account data access is a confirmed BOLA finding. Understanding how much API penetration testing costs helps teams budget for the depth of coverage their risk profile requires.
Code review surfaces the authorization logic, or its absence. Bugstrix engineers with experience reviewing API codebases look for the vulnerable pattern at the source level: does the data retrieval function accept an ID parameter, and does it include the authenticated user’s identity in the database query? A query that filters only by object ID, such as SELECT * FROM invoices WHERE id = ?, with no user ownership constraint is BOLA-vulnerable regardless of what the endpoint’s authentication middleware checks. Cybersecurity code review applied to API controllers and data access layers identifies these patterns systematically across an entire codebase, not only the endpoints that happen to be tested during a pen test.
API documentation review identifies untested endpoints. Complete API security testing includes auditing API specifications (OpenAPI/Swagger, Postman collections, internal docs) to identify all endpoints that accept object identifiers. Endpoints rarely exercised in normal flows (administrative endpoints, batch operations, legacy v1 paths) are frequently missed in testing and frequently missing ownership checks.
How Is BOLA Remediated?
Remediation requires code changes. Configuration changes, WAF rules, and rate limiting do not fix BOLA because the requests are structurally valid and the data returned is legitimate from the server’s perspective. The fix is enforcing ownership at the data access layer.
Enforce ownership in every query. Every database query or data access call that retrieves an object by ID must include the authenticated user’s identity as an additional constraint. A query for an invoice should be SELECT * FROM invoices WHERE id = ? AND user_id = ? where user_id comes from the verified session token, not from the request. If the object does not belong to that user, return 404 or 403, never the object belonging to a different user.
Never trust client-supplied ownership context. The remediation is violated if the fix moves the user ID into a request parameter rather than reading it from the server-side session. Both patterns have the same flaw: the server trusts the client to supply correct ownership context. The authenticated identity must come from the session or the validated token only.
Implement centralized authorization middleware. Endpoint-by-endpoint fixes are incomplete. A systematic secure code review of the kind Bugstrix performs, mapping every data access operation before writing a single fix, followed by a refactor that centralizes ownership checks makes it structurally difficult to add a new endpoint that forgets authorization. This architecture is more reliable than patching individual controllers.
Apply consistent identity and access management principles. Object-level authorization should be part of the application’s access control model from the design stage. Defining ownership relationships explicitly in the data model and enforcing them at the data access layer is more robust than adding authorization checks after the fact.
Test the fix with the same methodology used to find it. After implementing ownership checks, repeat the two-account cross-user test for every affected endpoint. The goal is a 403 or 404 for every cross-account object access attempt, not a 200 with an empty response, which can indicate a different implementation gap.
Frequently Asked Questions
What is the difference between BOLA and IDOR?
They describe the same vulnerability. IDOR (Insecure Direct Object Reference) is the original, broader term. BOLA is OWASP’s API-specific name for the same flaw applied to object identifiers in API requests. When you see BOLA in an API security report and IDOR in a web application report, they are describing the same underlying authorization failure.
Why is BOLA number one on the OWASP API Security Top 10?
It is the most prevalent and most impactful API vulnerability in practice. It is easy to introduce during development (the natural pattern is to trust the client’s ID), hard to detect with automated tools (requests look structurally valid), and often exposes large volumes of sensitive user data when successfully exploited. Mass data exposure incidents frequently trace back to BOLA at scale.
Can a UUID prevent BOLA?
No. UUIDs make object IDs harder to guess or enumerate, which reduces the likelihood of random discovery. But if an attacker obtains a UUID through any other means (a shared link, a log file, a different API endpoint, a phishing scenario) and the server does not verify ownership, the UUID provides no protection against BOLA exploitation.
Does adding authentication to an endpoint fix BOLA?
No. BOLA exists at the authorization layer, not the authentication layer. A fully authenticated user can exploit BOLA by requesting objects that belong to other authenticated users. The fix is not confirming the user is who they claim to be: it is confirming the user is allowed to access the specific object they are requesting.
Does GraphQL have BOLA?
Yes. Any GraphQL query that accepts an object ID argument and returns the associated object without verifying the requesting user’s ownership is vulnerable. The query structure looks different from a REST endpoint, but the authorization requirement is identical.
How long does it take to fix BOLA across a large API?
It depends on whether the application has centralized data access logic or not. Applications with a repository or data access layer pattern can implement ownership checks in a small number of places. Applications where authorization logic is scattered across individual controllers may require a significant refactor. Code review before the fix scopes the work accurately and prevents partial remediation.
BOLA and the Authorization Discipline Behind It
Broken Object Level Authorization is the most common API vulnerability for a reason: it is easy to write, natural to miss, and costly to discover after data has already been exposed. The architectural fix, enforcing ownership at the data access layer using the server-side authenticated identity, is straightforward to describe and requires discipline to implement completely across a large API surface.
Bugstrix combines penetration testing and code review to surface BOLA systematically: two-account cross-user testing to confirm exploitability, followed by data access layer review to identify every instance of the vulnerable pattern across the codebase. That combination surfaces findings that automated scanning misses and provides the code-level evidence needed to scope and implement remediation correctly.
Contact us to discuss API authorization testing for your application
