API A1 - Broken Object Level Authorization

OWASP Mapping

Rank	Vulnerability
A1	Broken Object Level Authorization (BOLA)
	└─ Advanced BOLA (ABOLA)

What is it?

Broken Object Level Authorization (BOLA) occurs when APIs fail to enforce proper authorization checks at the object level, allowing users to access resources they do not own by manipulating identifiers (e.g., user_id, order_id).

This is commonly known as Horizontal Authorization Bypass or IDOR (Insecure Direct Object Reference).

Advanced BOLA (ABOLA) extends this class of vulnerability to multi-step workflows and indirect object access paths, where exploitation is not possible through a single request, but through chained API interactions or secondary references.

Examples of ABOLA include:

• Accessing sensitive objects via indirect identifiers returned from prior API calls
• Exploiting object relationships across multiple endpoints
• Bypassing authorization through state transitions (create → fetch → modify)
• Leveraging cached or previously authorized object references

What are specific examples?

• Replacing {user_id} or {resource_id} in requests to access another user’s data
• Accessing objects via predictable or sequential identifiers
• Fetching related objects (e.g., invoices, receipts) without ownership validation
• Multi-step flows where authorization is only validated at the first step
• Using IDs obtained from one endpoint to access unauthorized data in another
• Missing authorization checks on secondary or nested resources
• Authorization enforced on UI but not on backend APIs

Test case FAQs

When is this test case applicable?

• Endpoints that accept object/resource identifiers (path, query, or body)
• APIs requiring authentication and handling user-specific data
• Workflows involving multiple API calls or object relationships (ABOLA)
• Both read (GET) and state-changing operations (POST, PUT, DELETE)

How does it work?

The test framework performs both direct and multi-step authorization validation:

BOLA (Direct)

1. Send request with victim credentials and capture response
2. Replay same request with attacker credentials
3. Compare responses for unauthorized data exposure

ABOLA (Advanced)

1. Discover object identifiers through prior API interactions
2. Traverse multi-step workflows (e.g., create → retrieve → update)
3. Replay chained requests using attacker context
4. Detect authorization gaps across steps and object relationships

Signals for detection include:

• Identical or structurally similar responses across users
• Unauthorized access to sensitive object fields
• Successful state-changing operations on чужие resources

What is the solution?

• Enforce object-level authorization checks on every request
• Validate ownership and access control server-side (never trust client input)
• Apply authorization consistently across all endpoints and workflow steps
• Avoid exposing raw or predictable object identifiers
• Use indirect references or scoped identifiers where possible
• Implement centralized authorization logic (e.g., middleware, policy engines)
• Log and monitor object access patterns for anomalies
• Perform continuous security testing for both direct and multi-step flows

False positives

• Endpoints intentionally returning shared/public resources (e.g., public content)
• Multi-tenant systems where access is legitimately shared across users
• Identical responses that do not expose sensitive or user-specific data

Such cases can be excluded from testing via configuration in the test plan.

References

OWASP API TOP-10 A1
BOLA / IDOR in API Security Encyclopedia