How to Test for BOLA/IDOR Vulnerabilities and Prioritize the Findings That Actually Matter

Before running any test, map the object identifiers used in the API. Object identifiers are the values in API requests that reference specific resources: user IDs in URL path parameters, order numbers in query strings, document IDs in request bodies, session tokens that embed user context. Each identifier type has a different BOLA risk profile.

Numeric sequential IDs (user_id=1234, order_id=5678) are the highest risk because they are trivially enumerable. An attacker who knows their own ID can systematically iterate through adjacent IDs to access other users' resources.

UUIDs and GUIDs reduce but do not eliminate BOLA risk. A UUID is not guessable, but if the API leaks other users' UUIDs in any response (for example, including a creator's user_id in a public-facing object response), those UUIDs can be used for BOLA testing.

Opaque tokens or hashed IDs (base64-encoded values, MD5 hashes of user attributes) are sometimes mistakenly assumed to provide security by obscurity. They reduce enumerability but do not eliminate BOLA if the identifier can be obtained through a related API call.

Map the identifier types by reviewing: the API's OpenAPI specification (if available), every URL path pattern in the application, request bodies that include ID fields, and responses that include references to other objects' IDs. This map guides the test plan and ensures no identifier type is missed.

Scenario 1: Read access to another user's object. With two test accounts (User A and User B), perform the API call to read User A's object (order, profile, document, message) using User B's authenticated session. Replace User A's object identifier in the request with a valid identifier from User A's data. If the response returns User A's data without an authorization error, the endpoint is vulnerable to BOLA for read access.

Scenario 2: Write access to another user's object. Using User B's session, make a PUT, PATCH, or POST request to modify User A's object. The most impactful write BOLA: modifying another user's email address (account takeover), adding items to another user's cart, modifying another user's payment information, or updating permissions or roles that affect another user's access.

Scenario 3: Delete access to another user's object. Using User B's session, issue a DELETE request for User A's resource ID. Successful deletion is a high-impact finding even if the data itself is not sensitive, because it creates a denial-of-service capability against any user's resources.

Scenario 4: Cross-tenant access in multi-tenant applications. This is the highest-severity BOLA variant. Create accounts in two different tenants (organizations, teams, workspaces). Using Tenant B's credentials, attempt to access Tenant A's resources by substituting Tenant A's object IDs. If the application does not enforce tenant isolation at the database query level, this produces cross-tenant data access -- a finding that typically requires immediate escalation and hotfix.

Scenario 5: Horizontal privilege escalation via role or permission ID. Some APIs allow users to specify a role_id or permission_id in requests. Test whether a standard user can escalate to an admin role by substituting an admin role's ID in the relevant request. This is BOLA applied to access control objects rather than data objects.

Manual testing of all five scenarios across all API endpoints is too slow for comprehensive coverage. Burp Suite's Repeater and Intruder, combined with the AuthMatrix or AuthZ extension, provide systematic coverage.

Session setup. In Burp Suite, configure two browser sessions with two distinct user accounts. Use Burp's "Match and Replace" feature or the Authorize extension to automatically test each request captured in Proxy with both sessions -- the session that originally made the request (expected to succeed) and the second user's session (expected to fail). The Authorize extension colors requests red when the second session receives the same HTTP 200 response as the original, indicating a likely BOLA.

Scoping the test to object endpoints. Filter the captured traffic to endpoint patterns that include object identifiers in the path (e.g., /api/v1/orders/{id}, /api/v1/users/{id}/settings). In Burp's Target > Site map, filter by path patterns containing ID segments. Focus testing on these endpoints.

Intruder for ID enumeration testing. For endpoints using numeric sequential IDs: configure Burp Intruder with the numeric ID as the payload position and a sequential number list ranging from your User A's known IDs to adjacent IDs (User A's ID minus 10 to plus 10, for example). Use the "Cluster Bomb" or "Sniper" attack type. Analyze the response length -- a response with content significantly longer than the "not found" or "forbidden" response indicates successful access to another user's resource.

GraphQL-specific testing. GraphQL APIs require testing object identifiers in query variables as well as in the query field arguments. Test introspection (if enabled) to understand the full object graph, then construct queries that reference objects by ID. The same five scenarios apply, but the access path may be through query arguments rather than URL path parameters.

Not all BOLA findings have the same impact. The classification framework determines escalation path and remediation priority.

Critical (immediate escalation, hotfix required):

• Cross-tenant data access in a multi-tenant application (accessing another organization's records)
• Read access to another user's credentials, payment data, PII, or health data
• Write or delete access that enables account takeover (modifying email, password reset token, or authentication method)
• Bulk enumeration capability that allows exfiltrating all users' records (sequential IDs that allow iterating through the entire user base)

High (expedited remediation, within 7 days):

• Read access to another user's private content that does not involve regulated data
• Write access to non-sensitive fields of another user's records
• Delete access to another user's resources (denial of service capability)

Medium (standard vulnerability remediation SLA):

• Read access to other users' non-sensitive metadata (usernames, public profile fields) that are not intended to be accessible but do not expose sensitive information
• BOLA in administrative endpoints that require elevated authentication to reach (attacker must first escalate to admin before the BOLA is reachable)

Low/Informational:

• BOLA findings where the object identifier is a UUID that is not leaked elsewhere in the API and cannot be enumerated without prior knowledge
• Findings in deprecated API versions that are disabled for external traffic

BOLA is fixed at the data access layer, not the presentation layer. Adding an authorization check after fetching the data is less secure than filtering at the query level.

The wrong pattern (fetch then check):

const order = await db.orders.findById(req.params.id);
if (order.userId !== req.user.id) {
  return res.status(403).json({ error: 'Forbidden' });
}
return res.json(order);

This pattern still fetches the data before checking authorization. Timing attacks and error message differences can sometimes leak information about whether the record exists. It is also more error-prone -- a developer forgetting the authorization check means the endpoint is fully exposed.

The correct pattern (filter at query):

const order = await db.orders.findOne({
  id: req.params.id,
  userId: req.user.id  // enforced at query level
});
if (!order) {
  return res.status(404).json({ error: 'Not found' });
}
return res.json(order);

By including the authenticated user's ID as a filter condition in the query, the database never returns records belonging to other users regardless of what ID is passed in the request. The response is identical for a non-existent record and a record belonging to another user, which prevents information leakage about the existence of the resource.

For multi-tenant applications, apply the same pattern at the tenant level: every query that touches tenant-scoped data must include the authenticated tenant's ID as a filter condition. This should be enforced at the data access layer (ORM, repository class, or database stored procedure) rather than relying on individual endpoint implementations to include the filter.

An API surface with dozens of endpoints requires systematic finding documentation to ensure all vulnerable endpoints are remediated, not just the ones that surfaced in the initial test.

Endpoint authorization matrix. Create a spreadsheet or security ticket board with one row per API endpoint (method + path). Columns: object identifier type, authorization check present (yes/no/not applicable), test status (not tested, tested clean, BOLA confirmed), impact classification, remediation status. This matrix provides at-a-glance coverage and prevents individual BOLA findings from being fixed in isolation while similar endpoints remain vulnerable.

Root cause categorization. Group BOLA findings by root cause rather than by endpoint. In most applications, BOLA findings cluster around specific code patterns: a shared data access module that does not enforce user scoping, a specific ORM query pattern, or a code generation template that does not include authorization filtering. Fixing the root cause pattern eliminates all endpoints that share it, rather than requiring individual fixes per endpoint.

Regression test for remediated endpoints. After BOLA remediation, add automated authorization tests to the API test suite that verify the fix. The test: create two authenticated user sessions, perform the previously-BOLA-vulnerable request with User B's session against User A's object ID, assert that the response is 403 or 404. These tests run on every deployment and prevent the vulnerability from reintroduced through refactoring.