What is BOLA: Broken Object Level Authorization Vulnerability

In this guide, we’ll learn what Broken Object Level Authorization is, how it can be exploited, real-world examples with vulnerable and secure code, and best practices for protecting APIs from unauthorized access.

What is Broken Object Level Authorization (BOLA)?

Broken Object Level Authorization (BOLA) is a security vulnerability where an application allows users to access objects (like data or resources) based on user input identifiers, without properly verifying whether the user is authorized to access those objects.

How Does BOLA Work?

BOLA exploits the fact that applications often rely on user-supplied identifiers to retrieve resources. If the application fails to validate if the user is permitted to access the requested resource, an attacker can tamper with identifiers to access or manipulate resources they don’t own.

Here’s a breakdown of how a BOLA attack typically unfolds:

1. Identify a Resource Access Pattern: The attacker finds an endpoint that accesses resources by identifier (e.g., /resource/{id}).
2. Modify the Identifier: The attacker changes the identifier (e.g., /resource/123 to /resource/456).
3. Test for Authorization: If there’s no proper authorization check, the attacker gains access to resources they should not be able to view or modify.

BOLA attacks are typically easy to perform but challenging to detect because they don’t necessarily involve any hacking tools—only an understanding of how the application manages resources.

Practical Examples of BOLA

Example-1: E-Commerce Platform

In an e-commerce application, users can view their orders, but they should not be able to view other users’ orders.

Let’s say we have an e-commerce platform with an API endpoint to retrieve order details:

GET /orders/{orderId}

If authorization checks are not properly implemented, a user could manipulate the orderId to view other users’ order information, potentially revealing sensitive data like items purchased, delivery address, and billing information.

Vulnerable Code

In this vulnerable code, the app fetches the order based on the orderId without verifying if the current user is authorized to view it.

// Vulnerable route handler to fetch an order by orderId
app.get('/orders/:orderId', async (req, res) => {
    const orderId = req.params.orderId;
    const order = await Order.findById(orderId); // No authorization check
    
    if (!order) {
        return res.status(404).json({ error: 'Order not found' });
    }
    
    res.json(order);
});

Problem: Any user can change the orderId and access other users’ order details.

Secure Code

In the secure version, we ensure that the order belongs to the logged-in user before allowing access.

// Secure route handler to fetch an order by orderId
app.get('/orders/:orderId', async (req, res) => {
    const orderId = req.params.orderId;
    const userId = req.user.id; // Assuming user information is in req.user
    
    const order = await Order.findOne({ _id: orderId, userId: userId }); // Access control check

    if (!order) {
        return res.status(403).json({ error: 'Unauthorized access or order not found' });
    }
    
    res.json(order);
});

Explanation: This code only returns the order if it belongs to the current user (userId matches order.userId). This prevents unauthorized users from accessing other users’ orders.

Example-2: Banking Application

In a banking application, users can view their own account details, but should not have access to other users’ account information.

Let’s say we have a banking application with an API endpoint to retrieve account details:

GET /account/{accountId}

If there is no verification that the accountId belongs to the logged-in user, then anyone could access any other user’s account by simply changing the accountId value.

Vulnerable Code

Here, the code simply fetches the account by accountId without checking if it belongs to the logged-in user.

// Vulnerable route handler to fetch account information by accountId
app.get('/account/:accountId', async (req, res) => {
    const accountId = req.params.accountId;
    const account = await Account.findById(accountId); // No authorization check
    
    if (!account) {
        return res.status(404).json({ error: 'Account not found' });
    }
    
    res.json(account);
});

Problem: A malicious user could simply change the accountId in the URL to view other users’ accounts.

Secure Code

In the secure version, we check if the accountId belongs to the logged-in user before returning the account data.

// Secure route handler to fetch account information by accountId
app.get('/account/:accountId', async (req, res) => {
    const accountId = req.params.accountId;
    const userId = req.user.id; // Assuming user information is in req.user
    
    const account = await Account.findOne({ _id: accountId, userId: userId }); // Access control check

    if (!account) {
        return res.status(403).json({ error: 'Unauthorized access or account not found' });
    }
    
    res.json(account);
});

Explanation: This code only returns the account if it belongs to the current user (userId matches account.userId). Unauthorized users cannot access other users’ accounts.

Why BOLA is Prevalent in APIs

APIs are especially susceptible to BOLA for several reasons:

• RESTful Design: REST APIs are designed around resources and use identifiers (such as userId or orderId) as part of the URL structure, making it easy for attackers to change values.
• Complex Authorization Requirements: APIs often require fine-grained, per-object access control, which can be challenging to implement and manage.
• Lack of Authorization Layers: Many developers assume that authentication is sufficient and overlook the need for additional authorization checks.
• Inadequate Testing: API security testing is often less rigorous than testing for traditional web applications, leaving authorization checks overlooked.

Risks and Impacts

BOLA vulnerabilities can have severe consequences:

• Data Exposure: Sensitive information, like personal details, financial records, or medical records, can be exposed.
• Unauthorized Actions: Attackers can perform actions like deleting or updating resources, causing financial or reputational damage.
• Privacy Violations: Exposing sensitive data can lead to legal repercussions, especially under regulations like GDPR or HIPAA.
• Loss of User Trust: Users may lose confidence in a service that fails to protect their data adequately.

Detecting BOLA Vulnerabilities

Manual Testing

Manual testing is often the most effective way to identify BOLA vulnerabilities. This involves:

• Tampering with IDs: Change identifiers in requests (such as userId, postId) and observe if unauthorized access is allowed.
• Testing Different User Roles: Use multiple accounts with different permissions to check if users can access each other’s data.

Automated Tools

Some tools can help detect BOLA vulnerabilities:

• Burp Suite: Its Intruder feature can automate identifier fuzzing to test unauthorized access.
• OWASP ZAP: ZAP has features for testing APIs and checking authorization.
• Postman: While not a vulnerability scanner, Postman can automate API requests and help test authorization logic.
• Custom Scripts: In some cases, custom scripts can be developed to automate checks for unauthorized access across various endpoints.

Prevention and Mitigation

Here are best practices to prevent BOLA vulnerabilities:

1. Enforce Object-Level Authorization

• Validate ownership of the object on the server side. Ensure that the logged-in user is authorized to access the requested resource.
• For each object retrieval or modification request, check if the current user has the necessary permissions to perform the action.

2. Implement Access Control Mechanisms

• Use robust access control lists (ACLs) or role-based access control (RBAC) to define and manage permissions consistently across the application.

3. Utilize Secure Identifiers

• Avoid using sequential or predictable IDs in URLs. Instead, use secure, unique identifiers (UUIDs or GUIDs) that make it more difficult for attackers to guess valid identifiers.

4. Perform Security Testing and Code Reviews

• Conduct regular penetration testing to simulate attacks and identify potential BOLA vulnerabilities.
• Use automated security tools (e.g., OWASP ZAP, Burp Suite) to scan APIs and endpoints for broken authorization vulnerabilities.
• Incorporate security code reviews into your development pipeline to catch authorization issues early.

5. Log and Monitor Access Attempts

• Log all access attempts, especially for sensitive objects, and monitor for unusual patterns (e.g., a single user attempting to access multiple different objects rapidly).
• Implement alerts for suspicious activity to detect unauthorized access attempts in real time.

Conclusion

Broken Object Level Authorization is one of the most critical security vulnerabilities in modern applications, especially REST APIs, which is why BOLA is listed as one of the top vulnerabilities in the OWASP API Security Top 10.

By securing APIs, using unique identifiers, implementing strong access controls, and performing regular testing, developers can mitigate the risk of a BOLA attack and protect sensitive user data from unauthorized access.