API1:2023 - Broken Object Level Authorization (BOLA)

Broken Object Level Authorization (BOLA) occurs when an API does not properly verify whether a user has permission to access a specific resource.

In practice, a user can access resources they do not own by modifying identifiers such as IDs, paths, or parameters.

BOLA happens when APIs rely on client-controlled identifiers without verifying ownership.

Typical flow: GET /api/users/123 with an authenticated token.

Core Issue

# vulnerable
resource = get_resource(request.params.id)
return resource

Correct Implementation

# secure
resource = get_resource(request.params.id)

if resource.owner_id != current_user.id:
    raise ForbiddenError()

return resource

Key concept: Object-level authorization means: Can this specific user access this specific resource? Without this check, BOLA exists.

From an attacker’s point of view, BOLA is not about breaking authentication. It is about testing whether object boundaries are actually enforced.

• Identify endpoints that expose object identifiers.
• Change IDs incrementally or try known valid values.
• Replay the same request with different accounts.
• Compare responses for unauthorized data differences.

If a request returns another user’s data after only changing an identifier, the system is vulnerable.

BOLA can occur in any API that exposes object identifiers. Multi-tenant systems are a common case where the impact becomes more severe due to broken isolation boundaries.

Example endpoint:

Expected behavior: users should only access invoices within their own tenant.

Vulnerable Logic

def get_invoice(tenant_id, invoice_id, claims):
    invoice = INVOICES.get(invoice_id)

    if invoice["tenant_id"] != tenant_id:
        raise NotFound()

    return invoice

• Sequential ID BOLA: attackers increment numeric IDs to access neighboring records.
• UUID BOLA: even when resources use UUIDs, missing authorization still exposes data if an attacker obtains a valid identifier.
• Nested Resource BOLA: endpoints like /users/{id}/orders/{order_id} may validate the order exists but fail to verify that it belongs to the specified user.
• Indirect BOLA: access is granted through secondary identifiers such as email, slug, reference code, or filename rather than a numeric ID.

1. Enforce object ownership on every request

Every time a resource is accessed, ownership must be verified explicitly.

resource = get_resource(resource_id)

if resource.owner_id != current_user.id:
    raise ForbiddenError()

• This check must happen after fetching the resource, not before.
• Never return a resource without validating who owns it.

2. Never trust client-supplied identifiers

IDs coming from the client are fully controlled by the user:

• URL paths
• Query parameters
• Request bodies

GET /api/users/123

Always combine lookup (resource_id) and authorization (who owns it).

Never rely on IDs alone to grant access.

3. Validate against authenticated context

Authorization must always be derived from server-side identity, not request input.

Basic check:

resource.owner_id == current_user.id

In multi-tenant systems, this alone is not enough. You must also validate tenant boundaries:

resource.tenant_id == current_user.tenant_id

Both conditions must pass before returning the resource.

4. Use proper access control models

Use a clear and consistent authorization model across your API.

• RBAC (Role-Based Access Control): define permissions by role (admin, user, viewer).
• ABAC (Attribute-Based Access Control): evaluate attributes such as ownership, tenant, department, and request context.

In practice, RBAC defines what actions are allowed while ABAC enforces which specific resources are accessible.

5. Centralize authorization logic

Avoid writing authorization checks directly inside every endpoint.

Instead:

• Use middleware or decorators.
• Implement policy layers.
• Create reusable authorization functions.

Example:

def can_access_invoice(user, invoice):
    return (
        invoice.owner_id == user.id and
        invoice.tenant_id == user.tenant_id
    )

This approach prevents inconsistent logic, makes rules easier to audit, and reduces security bugs as the system grows.

Detecting BOLA requires active testing of access boundaries.

Common techniques:

• ID manipulation: /users/1 to /users/2
• User context switching: test with different accounts
• Response comparison: same endpoint, different identifiers
• Pattern targeting: /users/{id}, /orders/{id}, /invoices/{id}

BOLA is simple but critical.

It exists whenever:

• APIs trust user input.
• Ownership is not verified.
• Authorization is assumed instead of enforced.

Every request must answer: Can this user access this specific resource?

If that check is missing, the API is already vulnerable.