What You Need to Know About Broken Object Level Authorization (BOLA)

Broken Object Level Authorization (BOLA) is the #1 vulnerability in the OWASP API Security Project’s API Security Top Ten in 2019. Using BOLA, an attacker exploits a vulnerable API endpoint by manipulating an arbitrary object identifier to exfiltrate or manipulate data they are not authorized to access. Authorization schemes can be complex, and it is easy for an API developer to miss an authorization check when the application state is passed between client and service.

The OWASP API Top Ten is being updated in 2023, and although the 2023 list is not finalized, the BOLA vulnerability easily holds on to the #1 spot in the current public release candidate.

Popular Attack Vector

API traffic continues to grow faster than all other network traffic, so it’s no surprise that probing for BOLA vulnerabilities is one of the first exploits tried by today’s hackers.

Source: Cloudflare

Recently, Sam Curry and friends demonstrated how hackers could remotely control, track, and transfer vehicles and leak personal information from over a dozen car manufacturers, including Mercedes-Benz, Ferrari, Porsche, and Toyota, by leveraging new API security flaws.

By exploiting BOLA vulnerabilities, hackers could take over any Ferrari customer account and access their records. By circumventing access controls on Ferrari APIs, they could also modify or delete employee back office administrator user accounts.

For a deeper dive into how these API weaknesses were exposed, see Sam’s vulnerability writeup.

BOLA in a Nutshell

So why are BOLA vulnerabilities so common? Here’s a simple example.

A user, kminchelle, logs into their account:

If the login is successful, the user typically receives an access token and some information about the user’s account, including an ID, 15, which is used to refer to kminchelle’s user account object during subsequent API calls.

For this example, we are using a dummy API service and fake data from https://dummyjson.com.

We check API access by making a second API call asking for kminchelle’s profile information using their access token and user ID:

As expected, the request succeeds. The data record has been truncated here, but significant personal information is disclosed.

Next, we make the same call, using kminchelle’s access token, but this time we try a different user ID, 11:

We get a successful response, obtaining personal information for user 11, acharlota, using kminchelle’s access token!

It is unlikely that one user should be authorized to see the personal information of another. This is a classic BOLA vulnerability.

It is likely that the access token was checked to make sure it was properly signed, but a further check was not made to ensure that the user associated with this token was authorized to access a different user’s ID.

Once a hacker has identified the BOLA vulnerability, they can fuzz the ID values to obtain information on additional users. In this example, it looks like user IDs are assigned sequentially, making this exploit even simpler to accomplish.

A hacker can exfiltrate user data and may potentially modify or destroy user data using other API endpoints. If a hacker can initiate a password reset request through a BOLA vulnerability, even a full account takeover is possible.

Shift Left to Fix?

Shift left is a common recommendation by security companies encouraging shifting security practices and testing earlier in the development process.

By shifting left, developers hope to catch problems earlier and fix them before they reach the production environment. 

Catching API vulnerabilities before your APIs are released to production is undoubtedly a good thing, but no matter how much you shift left, there’s no guarantee that you will identify and correct all such API vulnerabilities.

Shift to Approov to Prevent API Abuse

Strong run-time application security, which protects against both known and undiscovered vulnerabilities, is a critical operational defense.

Approov uses attestation techniques to ensure that only authentic and healthy applications can successfully make API calls. With BOLA, for example, If a healthy app will never make API calls with mismatched access tokens and user IDs, then even an undiscovered BOLA vulnerability will never occur during authentic operation.

Approov provides best-in-class attestation for Android and iOS applications, with live updates to security profiles and secrets, and dynamic certificate pinning to ensure API protection on and off devices.

If you are not certain you’ve caught all BOLA vulnerabilities, make sure you invest in mobile security such as Approov which prevents your APIs from being abused.