According to the OWASP (Open Web Application Security Project) 2019 API Security Project, Broken Object Level Authorization (BOLA) vulnerability, often also referred to as Insecure Direct Object Reference (IDOR), is the most severe and most common API vulnerability today.
Broken Object Level Authorization happens when an application does not correctly confirm that the user performing the request has the required privileges to access a resource of another user. Almost every company has APIs that are vulnerable to BOLA.
API1:2019 Broken Object Level Authorization
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using input from the user.
Impact of Broken Object Level Authorization (BOLA) in Cybersecurity
Object level authorization is an access control mechanism that is usually implemented at the code level to validate that one user can only access objects that they should have access to. An object is any information to which the application has access.
When an application includes a BOLA or IDOR vulnerability the application has a strong probability of exposing sensitive information or data to attackers. Once recognized, BOLA vulnerabilities can be exceptionally easy to exploit, frequently using simple scripting.
All the attackers need to do is to exchange the ID of their own resource in the API call with an ID of a resource belonging to another user. The absence of proper authorization checks enables hackers to access the specified resource. This attack is also known as IDOR (Insecure Direct Object Reference).
This issue is very common in API-based apps as a result of the server component not fully tracking the client’s state, and instead, counting more on object IDs, that are sent from the client to determine which object to access.
There are two main types of Broken Object Level Authorization (BOLA):
Based on user ID
The API endpoints receive a user ID and access the user object based on this ID. For example: /api/trips/get_all_trips_for_user?user_id=777
It’s usually easier to solve this type of BOLA because the authorization mechanism is straightforward — the developers simply fetch the ID of the logged-in user from the session (e.g.: `current_user.id`), and compare it with user_id from the GET parameter.
Things get more complicated when one user is supposed to manage other users by design (for example sub-users, regional manager, etc)
Based on object ID
The API endpoint receives an ID of an object which is not a user object. For example: /api/trips/receipts/download_as_pdf?receipt_id=1111
The reasons why we end up having Broken Object Level Authorization (BOLA) vulnerabilities in the code are quite simple: the lack of security control and human error. For example, an API that handles both sensitive and non-sensitive data. Some requests should have authorization checks and others shouldn’t therefore it’s easy to miss a check when writing code.
How to know if an API is vulnerable
It is in fact at risk in the following cases:
- API includes an ID of the resource, either in the URI, the request headers, or the body.
/api/restaurant1/financial_info
- API does not check permissions for the invoker to access the resource.
- The ID has a clear structure that can be
/api/123/financial_info
Current security scanning tools can’t detect Broken Object Level Authorization (BOLA) vulnerabilities. They can’t determine if a specific API endpoint should be authorizing a given user each time, this is a task for a human. It is crucial that all the APIs designers and developers are conscious of the vulnerability and are able to discover the existence of such vulnerability.
Broken Object Level Authorization vulnerabilities must be identified during the code development process, through regular architecture reviews, code reviews, and evaluating API request logs.
Here are two Broken Object Level Authorization examples:
How to Prevent Broken Object Level Authorization
- Extract the ID from an auth token rather than use the ID that has been sent from the client;
- Use random and unpredictable values as GUIDs;
- Use an authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database;
- Implement a proper authorization mechanism that relies on the user policies and hierarchy;
- Write tests to evaluate the authorization mechanism. Do not deploy vulnerable changes that break the tests.
Wrapping it up
Broken Object Level Authorization (BOLA) is a severe vulnerability, easy to notice and attack and prospective impacts are enormous. Trusting the information that is moved to the API by the customer is the origin of this vulnerability.
Object level authorization checks should be enforced in every API endpoint that receives an ID of an object and performs any type of action on the object. The checks should validate that the logged-in user does have access to perform the requested action on the requested object.
So we need to make sure authorization checks are in place.