Broken Object Level Authorization

If a user finds an endpoint, say, a user number in a browser URL, and changes that number to another and the API returns information that the users should not have access to, then we are dealing with a broken object-level authorization. So this vulnerability occurs when an API gives a user access to something they shouldn’t have access to ordinarily.

But what does that mean?

Broken object-level authorizations (BOLA) is a specific type of an insecure direct object reference (IDOR). As its name implies, a BOLA involves a user being able to directly access resources that they should not be able to access, using a user input functionality. This can be carried out in various ways, though typical methods involve changing an ID somewhere where the user can input information (whether in a form, cookies, URL…). The reason for the vulnerability existing as a result of simply changing an ID parameter is that the API does not check whether a user owns a resource before that user can do anything to it (such as modifying or deleting the resource).

An example of this would be a student being able to access another student’s grades by changing the requested student ID. Alternately, BOLAs can allow a malicious actor to gain access to a company’s customer details, which can then be used as part of social engineering or targeted phishing attacks. There is also a potential for complete account takeover, depending on the information that malicious individuals would be able to access. Therefore, broken object-level authorizations are a significant issue with potentially damaging consequences outside of the digital sphere, affecting people’s personal lives and their trust in companies, and can also cause legal issues with legislation such as GDPR.

What makes an API vulnerable?

These bugs are usually found in APIs which use an ID in the request. This can take the form of UserIDs, UUID, cookies, but also URLs and other forms. If changing the ID in the request allows a user access to information that they did not have access to previously, there is evidence of a broken object-level authorization. Therefore, this can be mitigated by ensuring that an identifier is combined with a check that any user has permission to access this resource. This can be as straightforward as an if statement, or using middleware. Obfuscating and randomizing user IDs is helpful, where possible; implementing a user authorization mechanism that rigorously checks for user access to a resource at every point where user input is possible (whether by cookies, text fields, URLs, etc). Using unit tests to ensure that code is automatically tested before being deployed.

What can attackers do with it?

A famous example of a BOLA (source and source) occurred in 2010 when Apple iPad users’ emails were leaked. AT&T had a functionality whereby a device’s SIM card ICC-ID could be submitted via an HTTP request and return an email address. By submitting a different ICC-ID (potentially belonging to another Apple customer), the utility would return a different email. This allowed attackers to access over 100,000 customer email addresses, including those of high-ranking individuals in the military, government, and media sectors.

The OWASP API Security Top 10 report mentions that “this has been the most common and impactful attack on APIs,” which is due to its high exploitability, ubiquity in APIs, and large potential for the data leak, alteration, or destruction, earning it the top spot in this Top 10 API security risk list.