Hunting Broken Object Level Authorization

Today, I am discussing BOLA, which is considered the number one vulnerability according to OWASP API.

Application Programming Interfaces (APIs) are essential to modern software development, with web APIs being the most common type.

They allow seamless communication and data exchange between various systems over the internet, acting as vital connectors that enable integration and collaboration among different software applications. At their core, APIs consist of defined rules and protocols that govern how different systems interact.

They specify data formatting requirements, outline access methods for resources, and define the expected structure of responses. APIs can be broadly categorized as either public, which are accessible to external parties, or private, which are restricted to specific organizations or groups of systems.

An object is a piece of code that processes and stores information. This concept is similar to objects in object-oriented programming (OOP). In simple terms, an object can represent various data types, such as a user ID, email, username, account details, personal notes, and more. Essentially, an object can be any data contained within an application.

Authorization is the process of granting access to specific objects or data within an application based on a user’s privilege level. It is implemented to maintain the confidentiality, integrity, and availability of that data. The primary purpose of authorization is to ensure that only intended users can access certain objects or functionalities. For instance, in web applications and APIs, certain features and information are restricted to administrators. This restriction is enforced by implementing checks on the user’s authorization level when they attempt to access those features. Now that we have a basic understanding of objects and the authorization process related to them, let’s discuss what broken object-level authorization means.

Web APIs enable users to request data or records by sending various parameters, including unique identifiers such as Universally Unique Identifiers (UUIDs), also known as Globally Unique Identifiers (GUIDs), as well as integer IDs.

However, if proper and secure verification is not in place to ensure that a user owns and has permission to access a specific resource, it can lead to data exposure and security vulnerabilities.

A web API endpoint is at risk of Broken Object Level Authorization (BOLA), also referred to as Insecure Direct Object Reference (IDOR), if its authorization checks — implemented in the source code — fail to adequately confirm that an authenticated user possesses the necessary permissions or privileges to request and view specific data, or to perform certain operations.

2. Received the JWT token

3. Now use this JWT token for authorization

4. Now check the current supplier information post JWT token authorization

5. Authorized suppliers can now download the yearly report using their current user ID, but there are BOLA vulnerabilities present. Authorized suppliers can also access reports from other companies.

To address the BOLA vulnerability, the endpoint /api/v1/supplier-companies/yearly-reports should include a verification step at the source code level. This step ensures that authorized users can only access yearly reports that are associated with their affiliated company. The verification process involves comparing the companyID field of the report with the authenticated supplier’s companyID. Access should only be granted if these values match; if they do not, the request should be denied. This approach effectively maintains data segregation for the yearly reports of supplier companies.

Thanks and Happy Hunting