OWASP Top 10 API security risks: Broken object level authorization

At the top of the list of Top 10 API Security Risks on the Open Worldwide Application Security Project® (OWASP) website is broken object level authorization (BOLA).

BOLA occurs when a threat actor successfully makes a request for data objects that should be restricted.

Attack vectors

Attackers exploit API endpoints by manipulating an object’s ID that is included in a request, tricking the API to return sensitive and protected data. BOLAs can occur in applications where the server component doesn’t fully track the client states and relies on object IDs to determine which objects should be accessible.

OWASP assigned an exploitability score of two, meaning it is easily exploitable by hackers.

Security weaknesses

According to OWASP, this is one of the most common and impactful attacks on APIs.

Even if the application implements an appropriate infrastructure to check authorizations, developers sometimes forget to use these checks before allowing access to sensitive objects. Access control detection is not necessarily responsive to automated static or dynamic testing, which means flaws can go undetected.

OWASP also scores BOLAs as a three on their scale of prevalence. This security threat is found in a wide variety of domains and apps.

Business impacts

Any time unauthorized access is granted to sensitive data, there is the risk of exposure and liability. Unauthorized access to some objects may also open the door to further breaches, including account takeovers.

BOLA exploits can lead to:

• Large-scale exposure of sensitive records
• Manipulation of records, including viewing, modifying, or deleting
• Privilege escalation
• Full takeover of admin accounts

How BOLA attacks work

Attackers probe for systems that use patterns within codes for requests. For example, they may test for BOLA flaws by changing user IDs or object IDs to see how the API responds. Once they find such a flaw and gain access, APIs without the proper security protocols in place are at significant risk. Once a threat actor gains access through the API, all data may be at risk.

Here’s how this might play out in a real-world scenario. Someone might gain access to a company’s system, either legitimately or illegitimately, using a customer ID. Once access has been authenticated, their identity is represented by a token. In an API request, they replace the customer ID they used for access with the ID of another user to gain access to another user’s personal data.

Once attackers know this works, they can then automate the process of substituting customer ID numbers in subsequent requests and exfiltrate additional records.

For example, a credential-stuffing attack might be used to breach a financial institution. By changing request identifiers, attackers can access different user accounts and potentially even transfer money or redirect data to different endpoints.

OWASP uses the example of an auto manufacturer that enables remote control of vehicles via API from a driver’s mobile phone using a vehicle’s VIN number. A threat actor could theoretically authenticate a device, then swap out another vehicle’s VIN, which is readily available online or on the vehicle itself. If the API fails to detect that the authentication does not belong to its actual owner, attackers might be able to access, start, or steal the vehicle.

Real-world examples

Such a breach is allegedly the cause of a breach of customer data at T-Mobile, which affected some 2.3 million subscribers in 2018. Another API-based attack may have also impacted 37 million T-Mobile users in 2023.

A vulnerability was discovered in the APIs of social media platforms belonging to Facebook and Parler. In the case of Facebook, these vulnerabilities could allow attackers to create posts on other users’ pages. While the posts were not visible in news feeds, they could be accessed through links.

Parler allowed API access to public posts without authentication. Since Parler post IDs were sequential, attackers could easily substitute ID numbers. Because there was no rate limiting in place, automation could extract data at an extremely high rate.

Detecting BOLA vulnerabilities

OWASP says BOLA rate a two when it comes to detectability. API scanning and testing are best practices for detecting BOLA vulnerabilities.

Detection starts with the evaluation of API endpoints and identifiers.

Engineers can test object IDS across an API lifecycle. For example, test cases can be created that require object IDs to be replaced, looking for error messages. If an error message is not returned, this can indicate potential exposure. Objects can also be tested for read, write, and delete actions. A combination of automated testing and manual penetration testing can help uncover BOLA flaws.

Unfortunately, traditional tools such as API gateways and web application firewalls will typically not protect against BOLA attacks. While API gateways are good for managing authentication, they are unable to uncover malicious requests. In most cases, these tools use signatures for detection and do not probe for unknown cases.

At the same time, broken object level authorization attacks can look similar to normal API requests with just a changed ID. Systems may be incapable of noticing anything out of the ordinary until exploits have already occurred.

Security teams should be on guard for large numbers of failed API requests, especially those that have authorization errors. As attackers probe for valid object IDs, it’s not uncommon to see significant unauthorized (401), not found (404), or forbidden (403) errors. Multiple requests for object IDs from the same authorization token may also indicate malicious activity.

Preventing BOLA vulnerabilities

OWASP offers several specific strategies to help prevent BOLA vulnerabilities, including:

• Implementation of proper authorization mechanisms that rely on user policies and hierarchy.
• Randomization of object IDs and globally unique identifiers (GUIDs) for records.
• Authorization mechanisms to check whether logged-in users have the authority to perform requested actions on records.
• Active testing to evaluate authorization mechanisms.

BOLAs have been a known exploit for some time. More than a decade ago, an API breach of Apple iPads occurred through AT&T, exposing the emails of some 100,000 users including high-ranking officials in government and media. Still, broken object level authorization remains at the top of the list for API security threats.