LAST UPDATED September 21, 2023
No. 1 on the 2023 OWASP Top 10 List of Critical API Security Risks, broken object level authorization or BOLA is both a dangerous and common API security vulnerability.
OWASP says of BOLA: “Attackers can exploit API endpoints that are vulnerable to broken object-level authorization by manipulating the ID of an object that is sent within the request. Object IDs can be anything from sequential integers, UUIDs, or generic strings. Regardless of the data type, they are easy to identify in the request target (path or query string parameters), request headers, or even as part of the request payload. .”
How Do BOLA Exploits Work?
BOLA exploits are possible in any endpoint that uses user-supplied input. The most common attacks involve enumerating IDs, either user IDs or object IDs, to see if the API will respond with data. For instance, an attacker could break into a banking system with a credential stuffing attack, and once in, take advantage of a BOLA vulnerability to change an identifier in a request and – without having to re-authenticate – access any number of accounts, transfer money from one account to another, etc.
Learn more about credential stuffing attacks in our recent research report.
OWASP offers this example:
“An e-commerce platform for online stores (shops) provides a listing page with the revenue charts for their hosted shops. Inspecting the browser requests, an attacker can identify the API endpoints used as a data source for those charts and their pattern /shops/{shopName}/revenue_data.json. Using another API endpoint, the attacker can get the list of all hosted shop names. With a simple script to manipulate the names in the list, replacing {shopName} in the URL, the attacker gains access to the sales data of thousands of e-commerce stores.”
BOLA attacks can have serious consequences, such as data leakage, privilege escalation, and account takeover. They are relatively easy to carry out and can be difficult to detect and fix. As such, they pose a significant threat to organizations and their customers.
Prevention of BOLA
There are a few best practices in the development phase that can help prevent BOLA vulnerabilities, including enforcing a standardized authorization strategy within all endpoints of your API, taking into account the user authorization level and the authorization requirements of all referenced resources.
How ThreatX Can Help
ThreatX can help both identify this vulnerability and block its exploitation. Due to our risk-based blocking, ThreatX can flag, watch, and, if necessary, block behavior that indicates a BOLA attack in progress.
Watching and Blocking BOLA
It can be difficult to detect if an attacker has exploited an instance of this vulnerability because the application would show no signs of an error. However, ThreatX continuously monitors each unique client/user and would detect probing/reconnaissance activity targeting this vulnerability. For example, we identify and flag resource ID enumeration, which would indicate a potential attempt to exploit a BOLA vulnerability. Other suspicious activity, such as repeated error responses, typically indicate an attacker is up to no good. If these behaviors reached a certain risk threshold, or are observed in conjunction with other suspicious attacker behavior (which they frequently are), we would block the attacker and record the events for later review.
Identifying BOLA
In addition, ThreatX provides visibility on potentially vulnerable API endpoints through a couple data points. First, the details for each attack (as described above) are correlated to each endpoint targeted. Second, failed requests are analyzed for various error conditions that indicate potential BOLA vulnerabilities.
How Our Approach Is Unique
Real-Time Blocking
Some API security solutions simply highlight potential API vulnerabilities, leaving security teams to investigate and recommend code changes. Other API solutions can identify an attacking IP, but require security teams to try to model the complex behavior in a third-party WAF (or try to block one IP at a time after the fact). ThreatX doesn’t just tell you about your API vulnerabilities like BOLA; we also block API attacks in real-time. ThreatX scans all inbound API traffic in real time, identifying and blocking attacks. ThreatX would recognize attacker behavior indicative of a BOLA attack, then flag and watch that user. This real-time monitoring enables ThreatX to execute advanced threat engagement techniques, such as IP interrogation, fingerprinting, and tarpitting. When a series of user interactions indicate a certain risk threshold has been met, ThreatX blocks the user.
Multi-Step Attacks
In many cases, attackers aren’t just going to attack with a BOLA exploit; they’re going to string together a series of attacks over time, often using bots. Countering this approach requires the ability to correlate attack traffic across multiple IPs, the use of advanced bot protection, and the ability to detect identifiers and techniques to associate the traffic to a unique attacker. ThreatX identifies and blocks more threats more accurately by analyzing behaviors from multiple vantage points – rather than requiring a single, significantly risky event or identifying a known signature. The ThreatX platform doesn’t look for signatures of attacks; it looks for attacker behavior. In this way, it can correlate several behaviors back to one attacker and can identify behavior that is suspicious, but wouldn’t be flagged by other security solutions, such as resource ID enumeration to exploit a BOLA vulnerability.
Learn more about how attackers leverage bots against APIs.
Less False Positives
As risk rises, ThreatX immediately blocks an attack – stopping the threat in its tracks. ThreatX’s blocking modes are designed to block malicious requests and deter suspicious entities from attacking your APIs, while allowing benign traffic and real users through. Legacy WAFs struggle with false positives because they only make blocking decisions based on rules, but attackers and legitimate users don’t always follow the rules. Sometimes a legitimate user who forgot their password looks like an attacker, and sometimes an attacker cycling through usernames and passwords looks like a legitimate user. ThreatX has the ability to tell the difference.
Learn more in A Security Practitioner’s Introduction to API Attack Protection. Or request a demo of the ThreatX solution.
