What Is Object Level Authorization (BOLA)?
Broken object level authorization is a security vulnerability that occurs when an application or application programming interface (API) provides access to data objects based on the user’s role, but fails to verify if the user is authorized to access those specific data objects. This vulnerability allows malicious users to bypass authorization and access sensitive data or execute unauthorized actions, which they would otherwise not have access to. BOLA forms a part of the larger family of authorization flaws, which are a major concern in application security.
The concept is relatively straightforward, but it can have far-reaching implications on the security of an application or a platform. Imagine a scenario where a user is granted access to a document which they should not be able to view. This document could contain sensitive information, such as personal data, financial information, or proprietary company information. If this document falls into the wrong hands, it can lead to potentially disastrous consequences.
In the OWASP Foundation’s list of top 10 API security risks for 2023, Broken Object Level Authorization is defined as the #1 risk, due to its widespread nature and the ease of exploitation.
This is part of a series of articles about data security
Importance of Object Level Authorization in Security
Data Protection
When properly implemented, object level authorization ensures that only authorized users can access specific data objects. This is achieved by using identifiers such as user IDs, role IDs, and object IDs to determine if a user has the necessary permissions to access a specific data object. By effectively controlling access to data objects, object level authorization plays a crucial role in protecting sensitive data from unauthorized access and misuse.
Learn more in our detailed guide to data protection
Preventing Unauthorized Actions
In any application or platform, different users have different roles, and these roles determine the actions that a user can perform. For instance, an administrator might have the ability to modify user accounts, while a regular user might only have the ability to view their account information.
Object level authorization plays a key role in enforcing these role-based access controls. By verifying if a user is authorized to perform a specific action on a data object, it prevents unauthorized users from performing actions that they are not permitted to.
Regulatory Compliance
Object level authorization is also crucial for regulatory compliance. Various laws and regulations, such as the General Data Protection Regulation (GDPR), the California Consumer Privacy Act (CCPA), and the Health Insurance Portability and Accountability Act (HIPAA), require businesses to implement appropriate security measures to protect sensitive data.
One of these security measures is ensuring proper access controls, which includes object level authorization. OLA also enables granular auditing at the object level, which helps organizations demonstrate that they have the proper controls in place.
Preventing Data Leaks
A data leak occurs when sensitive information is unintentionally exposed to unauthorized individuals. This can occur due to various reasons, including human error, system flaws, or security vulnerabilities such as object level authorization.
By effectively controlling access to data objects, object level authorization can prevent data leaks by ensuring that only authorized users can access specific data. This includes both internal and external users, as even employees can pose a threat if they gain unauthorized access to sensitive data.
How BOLA Attacks Work
Broken object level authorization attacks occur when an application fails to check if a user has the right to access a specific object, allowing them to access unauthorized data or perform unauthorized actions. Let’s see how these attacks work in more depth.
1. Identifying the Vulnerability
The first step in a BOLA attack is identifying the vulnerability. Attackers usually do this by observing how an application constructs its URLs or API endpoints. If they notice that the application is using direct references to internal implementation objects, it’s a clear sign that the application may be vulnerable to BOLA.
For instance, a URL like www.example.com/account/12345 might directly reference an account object. An attacker can change the account number and potentially access another user’s account, indicating a BOLA vulnerability.
Here is a more complex example shared by the OWASP project. Consider an online storage solution that lets users store, edit, and delete files. When a file is deleted, the following GraphQL mutation is sent to the API, containing the document ID:
The storage service deletes the document with the ID in the GraphQL mutation without any further permission checks, meaning that any user can potentially delete other user’s documents.
2. Manipulating the Reference
Once the attacker identifies a potential BOLA vulnerability, the next step is manipulating the reference to the object. This could be as simple as changing a digit in the account number in the URL, but could be very complex, depending on the URL structure and application logic.
If the application doesn’t correctly authorize the request, the attacker will be able to access the data or perform actions on behalf of another user. This could lead to data breaches, identity theft, and various other security issues.
3. Unauthorized Access
Following successful manipulation of the reference, unauthorized access is the final step. For instance, if the object is a user’s account data, an attacker could view personal information, modify account settings, or even perform actions as the user, like making transactions or posting messages. This unauthorized access is the goal of a BOLA attack and represents a significant security breach.
BOLA Vulnerability: Prevention and Mitigation Strategies
Here are several ways you can mitigate BOLA vulnerabilities in your applications and APIs.
Apply Proper Access Controls
Implementing proper access controls is the first step in preventing BOLA attacks. This means ensuring that every request to access a specific object is authorized.
A user should only be able to access the objects they have permission to. This could involve implementing access control lists or role-based access control mechanisms, which regulate access based on the user’s role and permissions.
Map Users to Their Accessible Objects
Mapping users to accessible objects involves keeping track of which objects each user is allowed to access. When a user makes a request, the application should always check if the user has the right to access the requested object. This can prevent unauthorized access and keep your data safe.
Implement Robust Authentication and Session Management
Robust authentication and session management are also crucial for preventing BOLA attacks. This involves ensuring that users are who they claim to be and that their sessions are properly managed.
For instance, a user’s session should be invalidated after a certain period of inactivity, and they should be required to re-authenticate to continue using the application. This can prevent attackers from hijacking sessions and accessing unauthorized data.
Use Random or Non-Guessable IDs
If an attacker can easily guess the ID of an object, it makes it easier for them to manipulate the reference and access unauthorized data. By making these IDs random or non-guessable, you can add an extra layer of security to your application and make it harder for attackers to exploit BOLA vulnerabilities.
For example, instead of using a sequential numeric ID such as 100123, 100124, 100125, each user’s ID could be a complex string such as liSb7HRrxGpp6^81.
Implementing API Gateways and Rate Limiting
Finally, implementing API gateways and rate limiting can also help prevent BOLA attacks. An API gateway can serve as a single entry point for all API requests, providing a layer of security by controlling how requests are handled.
One of the security features provided by API gateways is rate limiting. This can prevent attackers from making too many requests in a short period, which is often a sign of a BOLA attack. By limiting the number of requests a user can make, you can slow down an attacker and potentially prevent a data breach.
Protect APIs Against BOLA Attacks with Imperva
Imperva API Security provides continuous protection of all APIs using deep discovery and classification of sensitive data to detect all public, private, and shadow APIs to empower security teams to implement a positive security model.
The product works across legacy, hybrid, and cloud-native environments—including Kubernetes, AWS Lambda, legacy monolithic apps, standalone microservices, web proxies, or API gateways that integrate with other existing infrastructure.
Imperva API Security is a product uniquely designed to benefit both the security and development teams. As a core component of the Imperva Web Application & API Protection (WAAP) platform, organizations get a unified solution to protect legacy and cloud-native applications from online fraud, DDoS attacks, and API abuses.
