Bola Idor in APIs

BOLA stands for Broken Object Level Authorization, also known as Insecure Direct Object Reference (IDOR). This vulnerability occurs when an API fails to properly verify whether a user is authorized to access a specific object (data record) based on their identity and permissions.

The vulnerability gets its name from the typical attack pattern: an attacker modifies the object identifier in an API request to access resources belonging to other users. For example, changing a user ID or document ID in the URL or request body to access someone else's data.

Consider this vulnerable pattern:

GET /api/users/123/profile HTTP/1.1
Authorization: Bearer valid.token

If the API only validates that the token is valid but doesn't check whether user '123' belongs to the authenticated user, an attacker can simply change '123' to any other user ID and access their profile.

According to OWASP API Top 10, BOLA is the #1 most critical API security risk because it's widespread, easy to exploit, and can lead to complete data breaches.

BOLA vulnerabilities can have severe consequences depending on what data the API exposes. Common attack scenarios include:

• Data Theft: Accessing other users' personal information, financial records, health data, or proprietary business information
• Privilege Escalation: Modifying or deleting resources belonging to other users
• Business Logic Abuse: Exploiting workflows that depend on object ownership (like payment systems, order management)

Real-world impact examples:

GET /api/orders/456/details HTTP/1.1
Authorization: Bearer valid.token

An attacker could enumerate order IDs to view all customer orders, shipping addresses, and payment information. In a healthcare API:

GET /api/patients/789/records HTTP/1.1
Authorization: Bearer valid.token

This could expose sensitive medical records if the API doesn't verify the patient-doctor relationship.

BOLA often appears in RESTful APIs where resource IDs are predictable (sequential numbers, UUIDs, email addresses). The vulnerability is particularly dangerous because it requires no authentication bypass—the attacker uses their own valid credentials but accesses the wrong data.

Detecting BOLA requires systematic testing of object authorization across all API endpoints. Here's what to look for:

• Resource Enumeration: Can you access other users' resources by changing IDs in requests?
• Permission Boundaries: Does the API verify that the authenticated user owns or has permission to access the requested object?
• Cross-Tenant Access: In multi-tenant systems, can one tenant access another tenant's data?

Manual testing approach:

# Original request (your data)
GET /api/documents/123 HTTP/1.1
Authorization: Bearer your-token

# Test request (other user's data)
GET /api/documents/124 HTTP/1.1
Authorization: Bearer your-token

If both requests succeed and return different data, you have a BOLA vulnerability.

Automated scanning with middleBrick tests BOLA by systematically modifying object identifiers in API requests and verifying authorization checks. The scanner attempts to access resources using predictable ID patterns (sequential numbers, UUID variations) while authenticated with a single user's credentials. If the API returns data for modified IDs without proper authorization verification, middleBrick flags this as a critical BOLA finding.

middleBrick's BOLA detection runs across all 12 security checks in parallel, testing endpoints with different authentication states and object identifier modifications. The scanner provides specific findings including the vulnerable endpoint, the modified parameter, and the severity level based on the sensitivity of exposed data.

Preventing BOLA requires implementing proper authorization checks at the object level. Here are concrete remediation strategies:

1. Implement Object-Level Authorization

// Vulnerable code
const userId = req.params.userId;
const userProfile = await db.getUserProfile(userId);
res.json(userProfile);

// Secure code
const authenticatedUserId = getUserIdFromToken(req);
const requestedUserId = req.params.userId;

if (authenticatedUserId !== requestedUserId) {
    return res.status(403).json({ error: 'Access denied' });
}

const userProfile = await db.getUserProfile(requestedUserId);
res.json(userProfile);

2. Use Policy-Based Authorization

const policies = {
    canAccessUserProfile: (authUserId, targetUserId) => {
        return authUserId === targetUserId;
    },
    canAccessDocument: (authUser, document) => {
        return authUser.role === 'admin' || document.ownerId === authUser.id;
    }
};

// In your route handler
const document = await db.getDocument(req.params.docId);
if (!policies.canAccessDocument(authUser, document)) {
    return res.status(403).json({ error: 'Forbidden' });
}

3. Implement Resource Ownership Tracking

// Database schema with ownership
users:
  id: UUID
  email: string

documents:
  id: UUID
  ownerId: UUID (references users.id)
  content: text

// Query with authorization
const document = await db.query(
    'SELECT * FROM documents WHERE id = $1 AND ownerId = $2',
    [req.params.docId, authUserId]
);
if (!document) {
    return res.status(404).json({ error: 'Not found or access denied' });
}

4. Use UUIDs Instead of Predictable IDs

While UUIDs don't prevent BOLA by themselves, they make enumeration attacks more difficult:

// Generate secure UUIDs
import { v4 as uuidv4 } from 'uuid';

// Store and reference using UUIDs
const docId = uuidv4(); // e.g., 'f47ac10b-58cc-4372-a567-0e02b2c3d479'

The key principle: never assume that having a valid token means the user should access any specific resource. Always verify resource ownership or permissions at the object level.

BOLA vulnerabilities have caused some of the most significant data breaches in recent years. Notable examples include:

• CVE-2021-39174: A popular CRM system allowed users to access other organizations' data by simply changing the organization ID in API requests. Attackers could view and modify customer data across different companies using the same software instance.
• Facebook's Phone Number Search: A BOLA vulnerability allowed attackers to link phone numbers to Facebook accounts by enumerating user IDs, exposing millions of users' privacy settings.
• Uber's Internal Systems: Attackers exploited BOLA in Uber's internal applications to access sensitive internal tools and data, leading to a major breach in 2022.

These incidents demonstrate that BOLA affects companies of all sizes and industries. The vulnerability is particularly common in:

• Multi-tenant SaaS applications
• Healthcare and financial services APIs
• E-commerce platforms with user accounts
• Enterprise software with role-based access

The cost of BOLA vulnerabilities extends beyond data breaches. Companies face regulatory fines (GDPR, HIPAA), loss of customer trust, competitive disadvantage, and expensive incident response. OWASP estimates that BOLA vulnerabilities appear in 40-50% of APIs tested, making it the most prevalent API security issue.

Regular security scanning with tools like middleBrick can help identify BOLA vulnerabilities before attackers do. The scanner's systematic approach tests object authorization across all endpoints, providing developers with specific findings and remediation guidance to fix these critical vulnerabilities.