In API security, broken Object-Level Authorization (BOLA) is a vulnerability where an API fails to control access to specific properties within its exposed objects appropriately. Unauthorized users can view, modify, or delete sensitive data within these objects without permission to access the entire object.

Here's a breakdown of the critical aspects involved:

• Object: An object represents an API data structure containing various properties with specific values. Imagine a "user" object with properties like "name," "email," and "role."

• Property Level Authorization: This refers to the security mechanism that controls access to individual properties within an object. Ideally, users should only be able to access the specific properties they need for their designated tasks.

• Broken: This indicates that the authorization mechanism is flawed and allows unauthorized access to specific properties within objects.

Analogy: Imagine a filing cabinet with folders (objects) containing documents (properties). BOLA is like having a broken lock on the cabinet that allows unauthorized access to specific documents within folders, even if someone doesn't have permission to access the entire folder.

How Attackers Exploit BOLA:

Attackers can exploit BOLA vulnerabilities in several ways:

• Predictable Property Names: If property names are predictable (e.g., "user_id" + incrementing number), attackers might manipulate them to access unauthorized data about other users' properties (e.g., email addresses).

• Insufficient Validation: Weak input validation can allow attackers to inject special characters or manipulate requests to access properties they shouldn't be able to see. For instance, an attacker might trick the API into revealing another user's email address by manipulating part of the request URL.

• Privilege Escalation: In some cases, attackers might exploit BOLA to access sensitive properties that grant them higher privileges within the system. Imagine an attacker accessing a property that accidentally exposes an administrator password hash.

Consequences of BOLA:

BOLA vulnerabilities can have serious consequences, including:

• Data Breaches: Attackers might exploit BOLA to access sensitive information like personally identifiable information (PII) or financial data stored within specific properties of objects.

• Account Takeover: In some cases, attackers might exploit BOLA to access properties, allowing them to control other users' accounts. For instance, an attacker might gain access to a property containing a password reset token and use it to hijack another user's account.

• Disruption of Service: Attackers might modify sensitive properties within objects, potentially disrupting normal API operations or even causing system instability.

Preventing BOLA:

Here are some ways to prevent Broken Object Level Authorization vulnerabilities:

• Least Privilege: Implement the principle of least privilege, granting users access only to the specific object properties they need for their tasks. Don't expose all properties by default.

• Fine-Grained Access Control: Enforce granular access controls that differentiate between read, write, and delete permissions for individual object properties. It ensures users can only perform authorized actions on specific data elements.

• Input Validation: Implement robust input validation to prevent manipulation of requests and unauthorized access attempts. Validate all user input to ensure it conforms to expected formats and doesn't contain malicious code.

• API Security Testing: Conduct security testing to identify broken Object-Level Authorization vulnerabilities in your APIs. These tests can simulate various scenarios to see if unauthorized users can access sensitive properties within objects.

By following these practices, you can significantly reduce the risk of BOLA vulnerabilities and ensure your APIs have proper authorization checks for each property within exposed objects. It helps safeguard sensitive data and prevent unauthorized access to specific information within the API's data structures.

Discovery: The Foundation for Secure APIs

• Identifying External APIs: ThreatNG excels at discovering external APIs with which your programs interact. You can only address BOLA vulnerabilities if you know the data structures (objects) and properties they expose.

EASM and DRP: Building Knowledge

• External Threat Monitoring: EASM continuously monitors the external landscape for newly discovered vulnerabilities and emerging BOLA threats. It helps you stay informed about evolving attack techniques that exploit weaknesses in object-level authorization.

• Digital Risk Protection: DRP provides valuable insights about common BOLA vulnerabilities and best practices for securing access control to individual data properties within API objects. This knowledge empowers you to prioritize security efforts based on the specific APIs.

Collaboration is Key: ThreatNG and Complementary Tools

ThreatNG works seamlessly with other security solutions to create a robust defense against BOLA vulnerabilities. Here's a positive handoff example:

1. ThreatNG Discovers External APIs: ThreatNG discovers external APIs and the data structures (objects) they expose, along with any publicly available information about the properties within those objects.

2. Handoff to API Security Testing Tools: This information is passed on to dedicated API security testing tools like DAST (Dynamic Application Security Testing) or SCA (Software Composition Analysis) solutions.

3. Focused Testing for Property-Level Access: These tools analyze the API's behavior and identify weaknesses in controlling access to individual properties within objects. They can simulate various scenarios to test if unauthorized users can access specific properties they shouldn't have permission for. SCA tools can also identify vulnerabilities within libraries or frameworks the API uses that might contribute to BOLA risks.

4. Remediation and Continuous Monitoring: Developers address identified BOLA vulnerabilities in the API, and ThreatNG's EASM continues monitoring for new threats and newly discovered APIs.

Beyond Discovery: A Holistic View

While ThreatNG focuses on the discovery, a comprehensive approach goes further:

• DRP Insights: ThreatNG's DRP can provide insights into specific BOLA vulnerabilities associated with popular data formats or libraries used within the discovered APIs. It empowers security testers to tailor their analysis beyond core functionalities. For example, DRP might reveal known vulnerabilities in API libraries that can lead to insecure handling of object properties.

• Security Champions: ThreatNG can integrate with Secure Development Lifecycle (SDL) tools. By highlighting potential BOLA risks in discovered APIs, ThreatNG can encourage developers to consider property-level authorization from the beginning and write code that enforces granular access controls based on specific data needs.

A strong security posture relies on collaboration. ThreatNG acts as the initial scout, discovering external APIs and the objects they expose. It then works with API security testing tools, security teams, and developers to create a layered defense that minimizes the risk of BOLA vulnerabilities. By proactively identifying potential risks and collaborating with other tools, ThreatNG helps you ensure your APIs have secure access controls for each data property within exposed objects.