What is broken object level authorization (BOLA)?
Broken object level authorization (BOLA), also known as insecure direct object reference (IDOR) at times, is one of the largest threats to API security. It occurs when an API lacks strict policies to ensure that users are accessing only resources or data for which they are permitted.
It is the number one threat in the OWASP API Security Top 10 due to the relative ease of exploitation and the potential for damage.
Let’s consider an example of a web application where the user ID is part of the account page URL, such as /account/15, where 15 is the user ID. A BOLA vulnerability exists if an attacker can modify this ID to some other account ID and still view data from that account.
Why is BOLA dangerous
Data leakage: Other users’ sensitive information, including financial data, personal data, or medical data, can be exposed publicly through a BOLA vulnerability. This exposes companies to data protection laws like GDPR or HIPAA violations as well as to violate customer privacy.
Privilege escalation: A malicious user may change the profile of another person, acquire admin-level abilities, or destroy crucial information in resources that he/she does not own. This form of illegal activity can cause system intrusion, financial loss, and loss of one’s reputation.
Easy to exploit: It is easy to exploit BOLA by just modifying an object ID (like a user ID or order ID) in the URL or request parameters,even novice attackers are able to do so. As no sophisticated hacking tools are required, it is a low-effort, high-impact vulnerability.
Bypasses common defenses: Firewalls, WAFs, and even standard authentication are ineffective unless authorization checks are robust and enforced per object.
What causes BOLA
Missing object-level authorization checks: One of the most common causes of BOLA is the failure to implement proper authorization checks at the object level. While applications may verify that a user is logged in (authenticated), they often neglect to ensure that the user has the right to access or modify a specific resource.
Over trusting user input: APIs which take user-provided input, e.g., object IDs in the request path or body, tend to presume that the input is valid and reliable. Without ensuring that the object indeed belongs to or is accessible to the requester, the application is exposed to unauthorized access.
Use of guessable object identifiers: Most applications utilize easy-to-guess identifiers such as sequential numeric IDs (e.g., /user/1, /user/2). These can easily be modified by attackers to view other users’ data if backend authorization checks are not implemented.
Inadequate security testing of APIs: As a result of insufficient specialized security testing throughout the development life cycle, BOLA vulnerabilities are usually overlooked. Developers and testers may ensure that endpoints work as expected, but they may not test for the potential of unauthorized access to objects by manipulation.
Methods to prevent BOLA
Always do object-level authorization checks: Once the user has been authenticated, the system must verify that the user is allowed to access or manipulate the specific object in question. This ensures that resources that they do not own or are not allowed to access cannot be accessed by even authorized users.
Utilize centralized authorization logic: Employ a central system, like middleware or an access-control service, instead of scattering permission checks unevenly across controllers or services. This approach ensures uniform enforcement across the application and reduces the likelihood of skipped checks.
Avoid predictable identifiers: Attackers find it easier to guess and obtain access to more objects when sequential IDs (e.g., 101, 102) are utilized. Unauthorized discovery becomes more challenging when a layer of obscurity is added when UUIDs or hashed identifiers are employed instead.
Perform security testing: Regularly test your APIs and endpoints for BOLA vulnerabilities using automated and manual methods and ensure unwanted access is properly blocked.
Broken Object-Level Authorization is a significant but sometimes forgotten vulnerability, which can have severe implications like illegal data access, privilege escalation, and privacy breaches.
With APIs now being the building blocks of modern applications, it is necessary and not a choice to ensure that each request is properly allowed at the object level.
