What Is broken object level authorization (BOLA)?

Because BOLA vulnerabilities arise from flaws in application logic rather than simple input validation errors, they are often difficult for traditional vulnerability scanners to detect. That makes BOLA a very attractive target for cybercriminals seeking to access sensitive data. Several high-profile data breaches have been linked to authorization vulnerabilities in APIs, including incidents where attackers manipulated object identifiers to access sensitive data.

BOLA vulnerabilities are often the result of insecure coding practices, where developers fail to write code that properly validates user input or that checks permissions before allowing a user to access an object, even if validation has been granted before.

The BOLA vulnerability is usually caused by flaws in the authorization process, including:

• Failure to validate user-supplied inputs such as  user ID or object ID
• Misconfiguration of authorization checks
• Failing to enforce object-level authorization when APIs reference resource identifiers (such as user IDs or object IDs) in requests
• Failure to check permissions upon each individual request
• These weaknesses often appear in REST and GraphQL APIs alike, especially when APIs directly reference internal objects.

BOLA abuses the process of object level authorization, an access control mechanism for APIs, a process that defines whether users have permission to access data objects. An object is any information that an application can access or use, such as database records or files. When a user is granted authorization, the permission may include the authority to read-only, edit, or add/delete. Permissions may differ based on different user groups and roles. For example, a user may be allowed to use specific database records but not to change or delete them.

Broken Object Level Authorization occurs when an application does not correctly confirm that the user requesting access actually has the required privileges to access an object or the resources of another user. As a result, users can access other users’ data. Once this happens, hackers can automate requests and gain other authorized access to thousands of records.

For hackers, the first step in a BOLA attack is identifying the vulnerability by testing applications to see how it constructs URLs or API endpoints. Applications that reference object identifiers in API requests—such as user IDs, order numbers, or document IDs—can be vulnerable if object-level authorization checks are not enforced.

To exploit the vulnerability, hackers can use very simple scripting that exchanges the ID of their own resource in an API call with the ID of a resource that belongs to another user. Because the API does not properly check the authorization, it may provide the hacker with access to the requested resource.

Example:

An API endpoint such as:

https://api.example.com/users/12345/orders

If the API does not confirm ownership, an attacker can replace 12345 with another user ID and gain access to someone else’s data. This class of attack is closely related to IDOR (Insecure Direct Object Reference) vulnerabilities.

Once attackers identify a vulnerable endpoint, they can automate requests to extract or modify thousands of records, dramatically increasing the scale of data exposure.

Because BOLA targets authorization rather than authentication, BOLA attacks are considered both easy to execute and highly dangerous. This vulnerability may allow attackers to:

• View unauthorized data
• Access sensitive information belonging to a different user
• Hijack administrative accounts
• Steal data for financial fraud and identity theft

Scanning and testing APIs is the most effective way to uncover BOLA vulnerabilities. These steps may include:

• Reviewing all API endpoints and identifying the uses
• Writing test cases that require object IDs to be replaced — if error messages are not returned, the API may be vulnerable
• Testing objects for read, update, edit, and delete actions
• Reviewing functions that access objects through secondary routes
• Automating the process with API testing solutions to find flaws more quickly
• Conducting manual penetration testing to uncover flaws that live in an API’s business logic layer

Security teams can take several steps to protect their organizations against Broken Object Level Authorization. These measures help reduce the likelihood of unauthorized access and account takeover:

• Implement robust authorization. Having strong authentication is not enough — all API calls must also be authorized, and the authorization mechanism should be managed from one location for all APIs. Security teams must constantly test well-controlled authorization policies to make sure they’re free of loopholes and logic flaws.
• Map users and accessible objects. Keeping track of which objects can be accessed by each user makes it easier to determine whether a user has a right to access an object upon request.
• Use random IDs. Universally unique identifiers (UUIDs) are far more difficult for unauthorized attackers to guess than auto-incrementing IDs. By using IDs that comprise a combination of numbers, letters and symbols, organizations can minimize the risk of malicious tampering.
• Deploy API gateway security and rate limiting. Serving as a single entry point for all API requests, an API gateway provides greater security by controlling how requests are managed. Rate limiting prevents attackers from making too many requests in a limited period of time — a hallmark of BOLA attacks.
• Focus on the business logic layer. BOLA flaws are difficult to find because they often exist in an API’s business logic layer. IT teams must meticulously test to find vulnerabilities that may not be discovered with vulnerability scanners.
• Encrypt sensitive data. Encryption ensures the data will be harder or impossible to read if it is exposed via a BOLA attack.
• Adopt a Zero Trust framework. Zero Trust requires all users be authenticated and authorized before accessing resources. Under a Zero Trust model, each API call must be authenticated, and then authentication mechanisms must determine whether the user is allowed to access the resource.
• Implement AI-based API security testing AI testing platforms deliver comprehensive and continuous testing of APIs.