How to Prevent and Fix Broken Object Level Authorization (BOLA) in APIs

It is becoming increasingly common for APIs to be exploited by threat actors. Broken Object Level Authorization (BOLA) attacks are also on the rise and represent a critical general vulnerability. 

The problem is relevant for a broad range of teams, including API-first companies, fintech teams, SaaS platforms, and mobile app backends. The impact of a BOLA vulnerability is significant, including data exposure and regulatory fines.

API traffic is now outpacing web traffic, which means API attacks are on the rise. Industry reports indicate that attacks on APIs are skyrocketing, with many companies being targeted over the last year.

What Is Broken Object Level Authorization (BOLA)?

Broken Object Level Authorization (BOLA) is a vulnerability in which an application fails to verify whether a user is authorized to access a specific object or resource. An attacker can abuse this vulnerability by using the identifier of an object in an API request to retrieve private or confidential data. The application does not properly enforce authorization on access to sensitive information. This is one of the most frequent and dangerous API vulnerabilities.

This can manifest in various forms of APIs:

• RESTful endpoints: An attacker can tamper with a user ID or document ID in the URL. For instance, if there is a valid request to look up an order at https://api.example.com/orders/123, a malicious user might try to change the ID in the URL to https://api.example.com/orders/124 or some other user’s order number to see if they can access the other user’s order.
• GraphQL queries: An attacker could modify an ID variable in a query to obtain data for a different user.
• File download links: It may also allow unauthorized users to download confidential files by guessing or manipulating the file identifier in the download link, via BOLA.

IDOR is interchangeable with BOLA (Broken Object Level Authorization), which is its namesake on the OWASP API Security Top 10. IDOR is fundamentally an authorization flaw. It takes advantage of a flaw in the logic that, in theory, should prevent users from being able to do anything with resources that they don’t own or don’t have explicit permission to use.

Why is Astra Vulnerability Scanner the Best Scanner?

• We’re the only company that combines automated & manual pentest to create a one-of-a-kind pentest platform.
• Vetted scans ensure zero false positives.
• Our intelligent vulnerability scanner emulates hacker behavior & evolves with every pentest.
• Astra’s scanner helps you shift left by integrating with your CI/CD.
• Our platform helps you uncover, manage & fix vulnerabilities in one place.
• Trusted by the brands you trust like Agora, Spicejet, Muthoot, Dream11, etc.

Let’s Talk Get Started

How Does BOLA Impact Security, Compliance & Operations?

The implications of insecure direct object references extend beyond just a minor bug. They introduce several risks from a security, compliance, and day-to-day operational perspective.

1. Data Breaches and Unauthorized Access

The simplest outcome of IDOR is data leakage. Authorization is compromised, and as a result, attackers can gain unauthorized access to any data that can be retrieved through an API endpoint.

This might include PII, financial data, health data, or proprietary business data. However, an attacker doesn’t have to compromise an account; they just need a valid login and be able to guess the resource IDs of other users.

2. Privilege Escalation Attacks

Privilege escalation via BOLA is well-explored. A regular user could exploit a BOLA vulnerability to gain unauthorized access to admin capabilities or sensitive data. For example, a user could tamper with a request to update their user profile and try to add a field isAdmin: true/. 

If the endpoint doesn’t verify authorization properly, the user could gain administrative privileges. An IDOR vulnerability could allow a standard user to access functionality reserved for higher-privilege roles. 

For example, consider an application where administrators can access a special audit log by using the/api/logs/{log_id} endpoint. A regular user might find this endpoint and try to access a log by guessing its ID (e.g., /api/logs/1). If the endpoint fails to check that the user making the request is an administrator, the user will have successfully escalated their privileges to view sensitive admin-only data.

3. Customer Data Exposure

For a business that handles user data, such as customer IDs, BOLA poses an immediate risk to its customers. One vulnerability stands between every customer’s data being exposed en masse.

Not only does this erode customer confidence in the business, but in many cases, it also results in legal action being taken against a company and substantial damage to its reputation. In a competitive market, a lack of security can also be a deciding factor for users when choosing which service to use.

4. Compliance Issues

Failing to address the elimination of BOLA can lead to significant compliance issues in data protection statutes. Most compliance standards require strict enforcement of access controls, and IDOR is an abuse of that regulation.

• GDPR Article 32 (Security of Processing): This states that companies must establish technical and organizational security measures proportionate to the risk. A BOLA vulnerability illustrates a failure in data processing security, as unauthorized individuals can access private data.
• HIPAA 164.312(a) (Access Control): The HIPAA Security Rule mandates that covered entities “implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights.” 
• SOC 2 Type II CC6.1 (Logical Access): The SOC 2 Security criteria require that access to data be limited to those who have a legitimate need to access it. A BOLA vulnerability would almost certainly appear as a finding or exception during a SOC 2 engagement because it demonstrates that logical access controls are being bypassed.
• PCI DSS Requirement 7 (Restrict Access): Requirement 7 states that access to cardholder data must be limited on a need-to-know basis. BOLA issues can often result in unauthenticated access to payment data, thereby compromising this critical concept of PCI DSS.

How to Detect IDOR/BOLA Vulnerabilities

BOLA vulnerabilities can be detected with an automated scanner and further tested manually. Let’s discuss a few different ways to detect them.

1. Parameter Manipulation Techniques

Manually identifying BOLA has one primary technique: parameter manipulation. This involves identifying all user-controllable inputs that are used as object identifiers in an API request.

These identifiers may appear in the URL paths, query parameters, request body, or HTTP headers. The process is straightforward:

1. Log in as a user and make a legitimate request to access a resource.
2. Capture the request and identify the object’s ID (e.g., orderId: “A-554”).
3. Log in as a different user at the same privilege level.
4. Replay the first user’s request, but with the second user’s session token.
5. If the second user gains access to the first user’s resource, an IDOR vulnerability exists.

2. Horizontal vs. Vertical Privilege Escalation Testing

BOLA testing can be split into two types:

• Horizontal Privilege Escalation: This refers to verifying access among users with the same privilege level. For example, test whether User A can see User B’s data (such as invoices, messages, and profile information). It is the most frequent variation of BOLA.
• Vertical Privilege Escalation: These are cases where a user with lower privileges attempts to access the data or functionality of a user with higher privileges. For instance, a user may attempt to access an admin endpoint, such as /api/admin/users/123, by using various URL tricks.

3. Testing Different User Roles and Contexts

The successful testing involves verifying every API endpoint from the perspective of all user roles specified in the application. An endpoint that appears secure for anonymous users may be exposed when accessed by a manager or support agent.

It is essential to create a matrix of user roles and their intended permissions, then systematically test that the API enforces these permissions without fail. 

4. Automated Scanning Tools

Although manual testing is also crucial in identifying business logic issues, automated tools can help uncover BOLAs.

• Astra Security: Tools like Astra Security offer an exhaustive API vulnerability scanning, which includes specific testing for IDOR and other types of vulnerabilities. They help automate the process of submitting manipulated requests and inspecting resultant responses to identify potential authorization failures, and are ideal for continuous security testing.
• OWASP ZAP: Zed Attack Proxy (ZAP) is a widely used open-source security tool that can be used to scan an API. With a bit of setup and scripting, ZAP can be configured to swap out IDs in proxy traffic and automatically detect BOLAs.

Elevate your API security posture. Download our free checklist now.

Download Checklist

How To Handle Broken Object-Level Authorization (BOLA) in APIs

A security-first attitude requires addressing this with authorization as the core part of application logic, rather than adding it as an afterthought. The fundamental rule is very simple: never trust the user. Every single request that hits a resource must be validated on the server side.

1. Implement Proper Authorization Checks at Every Endpoint

The simplest step is to put an authorization check in each function that accesses a resource. Before fetching or changing any piece of information, the application should first verify that the current authenticated user is authorized to perform that action with the particular data.

For instance, when a user requests an order detail, we can find the order not just by its ID but also by its ID and the user’s ID.

• A flawed check: SELECT * FROM orders WHERE order_id = ? 
• A correct check: SELECT * FROM orders WHERE order_id = ? AND owner_id = ?

2. Use Attribute-Based Access Control (ABAC)

ABAC offers a flexible and powerful approach to managing permissions. In contrast to static user roles, ABAC describes rules that allow access based on the attributes of both the user and the resource, and applies to the environmental context in which access is requested.

For instance, a policy could say: A user must be able to view a document if the user.department attribute matches the document.department attribute. This is a more fine-grained approach and is more applicable to complex business rules, as opposed to Role-Based Access Control (RBAC), which is traditionally used.

3. Validate User Context Before Object Access

At the start of any data access operation, always verify the user’s context. This means retrieving the user’s identity from a secure session token/API key and using that identity as a filter in your database queries or code.

This check needs to be implemented at a higher level of the application (for example, middleware or a library). 

4. Indirect Object References

By referencing objects with the equivalent of index numbers (1, 20, 300), you make it simple for attackers to guess the IDs of other objects. A better way to reference is by using indirect objects. 

These are unspecific, randomly generated tokens, such as UUIDs (Universally Unique Identifiers) or other secure tokens, that map back to the real database ID on the server. For example, instead of doing this GET /api/invoices/101, use a UUID /api/invoices/a71a742c-e309-48fe-9366-a33b9c7a91a1. 

This makes it difficult for an attacker to iterate over other users’ invoices. Still, this should be viewed as a defence-in-depth measure, and not used as a replacement for proper authorisation controls. If there’s no authorization check, an attacker can still access the resource if they obtain a valid UUID through another means.

5. Resource-Based Permissions

For more advanced use cases involving complex sharing, consider resource-based permissions. In this data model, permissions are assigned to one or more resources and are not solely determined by a user’s role.

For example, User A might have view and edit access to document-123 but view-only access to document-456. Within this model, fine-grained control is possible, often found in collaborative applications such as Figma or Google Docs.

6. Context-Aware Authorization

One of the more sophisticated and successful strategies is context-sensitive authorization. This approach is more advanced than static permissions, as it considers the request itself. Authorization decisions can be based on the user’s IP address, geographic location, time of day, or recent user interactions.

You might block a request to sensitive data, for instance, if it’s made from an unknown device or place, even if it was authorized with correct credentials. It is a powerful layer of security that has proven to be very difficult for attackers to get around.

Common Mistakes to Avoid

• Client-side authorization only: A common mistake is trusting the client-side app (such as a JavaScript frontend or mobile app) to enforce permissions. The client can always be manipulated. All authorization decisions need to be made and implemented on the server.
• Inconsistent permission checks: Another mistake is to secure writes (POST, PUT) but to expose reads (GET). Attackers always have the means to steal sensitive data; this is also true of any unprotected read endpoints. Any kind of checks must be performed in the same manner for all actions and at all endpoints.
• Predictable object IDs: As mentioned earlier, sequential or predictable IDs for resources are a risk. Use random, non-guessable IDs for any objects sent to the user.
• Over-privileged API keys: API keys are widely used in service-to-service communication. One mistake would be to use a single, highly privileged API key for multiple services. If that key is leaked, the resulting carnage can be widespread. Instead, use scoped API keys that only have the permissions necessary for their role.

Final Thoughts

While the concept behind Broken Object Level Authorization may seem simple, its impact is severe. Securing your APIs against IDOR is not a choice but a basic necessity if you are building secure and reliable applications. The answer is strict policy enforcement when it comes to authorization.

Take the initiative by adding server-side authorization checks to all endpoints, using unguessable resource identifiers, and embedding security into the development lifecycle to prevent IDOR and secure your user data. Astra Security helps teams proactively uncover and fix BOLA and other critical API vulnerabilities through continuous, expert-led pentesting.

Astra Pentest is built by the team of experts that helped secure Microsoft, Adobe, Facebook, and Buffer

Book a Demo View Pricing

FAQs