Broken Object Level Authorization

Broken Object Level Authorization (BOLA) is the most prevalent and critical API security vulnerability, consistently ranked as the top risk in the OWASP API Security Top 10. This vulnerability occurs when an API endpoint exposes object identifiers in its requests—such as database IDs, UUIDs, or sequential integers—without performing adequate authorization checks to verify that the requesting user has permission to access or modify the specified resource.

BOLA vulnerabilities are fundamentally an access control failure at the object level. APIs typically use some form of identifier sent by the client to determine which data object to return or manipulate. When the server-side logic fails to validate that the authenticated user is authorized to perform the requested action on the specific object referenced by the identifier, any authenticated user can potentially access or modify any object in the system simply by enumerating or guessing valid identifiers.

The impact of BOLA is particularly severe in multi-tenant environments, healthcare systems, financial platforms, and any application where data segregation between users is a fundamental security requirement. Exploitation is trivially simple—often requiring nothing more than changing a numeric ID in a URL—making this vulnerability extremely attractive to attackers and frequently exploited in real-world breaches.

BOLA exploitation follows a straightforward pattern. An attacker first authenticates to the API using their own legitimate credentials. They then examine API requests made during normal application usage, identifying endpoints that reference specific objects via identifiers in URL paths (e.g., /api/v1/users/1234/orders), query parameters (e.g., ?account_id=5678), or request body fields. The attacker then systematically modifies these identifiers to reference objects belonging to other users.

At a technical level, the vulnerability exists because the authorization middleware or business logic only verifies that the requester has a valid session or token, but does not enforce object-level ownership checks. For example, a typical vulnerable endpoint might decode a JWT to extract a user ID and validate the token signature, but then directly use the object ID from the URL path to query the database without a WHERE clause constraining results to the authenticated user's scope. The database faithfully returns the requested record regardless of ownership, and the API serializes it back to the attacker.

Advanced BOLA exploitation techniques include using predictable ID patterns (sequential integers, timestamps) to enumerate all resources, leveraging GraphQL introspection to discover object relationships, chaining BOLA with other vulnerabilities like mass assignment, and exploiting batch or bulk endpoints that accept arrays of object IDs. In REST APIs with nested resources, BOLA may exist at multiple levels of the resource hierarchy, allowing attackers to traverse relationships between objects they do not own.

• Unauthorized access to sensitive user data including personal information, financial records, and health data across all accounts in the system
• Data modification or deletion of resources belonging to other users, potentially corrupting business-critical information
• Complete compromise of multi-tenant data isolation, allowing one tenant to access another tenant's entire dataset
• Regulatory compliance violations under GDPR, HIPAA, PCI-DSS, and other frameworks due to unauthorized data access
• Account takeover when BOLA is present in account management endpoints such as password reset or email change functions
• Horizontal privilege escalation allowing any authenticated user to act as any other user in the system

1. Implement a centralized authorization mechanism that enforces object ownership checks on every API endpoint. Use a policy engine or middleware that automatically verifies the requesting user's relationship to the target resource before processing the request.
2. Replace sequential or predictable object identifiers with non-guessable UUIDs (v4) to make enumeration attacks significantly more difficult. Note that this is a defense-in-depth measure, not a replacement for authorization checks.
3. Add authorization unit tests for every API endpoint that explicitly test cross-user access scenarios. Each test should verify that User A cannot access User B's resources even with a valid session token.
4. Implement database query scoping that automatically filters results by the authenticated user's tenant or ownership scope. Use ORM-level middleware or repository patterns that inject ownership constraints into every query.
5. Deploy API gateway policies that validate object ownership at the edge before requests reach backend services. Use request transformation to inject authenticated user context into all downstream calls.
6. Conduct regular automated BOLA testing using tools that enumerate object IDs across authenticated sessions and flag any successful cross-user access.
7. Implement comprehensive audit logging that records the authenticated user, requested object ID, and authorization decision for every API call. Alert on anomalous patterns such as a single user accessing many different object IDs in rapid succession.

Testing for BOLA requires two or more authenticated user sessions. Begin by mapping all API endpoints that accept object identifiers using tools like Burp Suite or OWASP ZAP to proxy application traffic. Document every parameter that references a specific resource—URL path segments, query parameters, request body fields, and HTTP headers. Create an inventory of all identifier patterns used across the API surface.

Execute horizontal privilege escalation tests by authenticating as User A, capturing a request that accesses User A's resource, then replaying that exact request but substituting User B's object identifier while retaining User A's authentication token. Tools like Burp Suite's Autorize extension automate this by maintaining two sessions and replaying every request from Session A using Session B's credentials. For GraphQL APIs, use tools like InQL to discover object relationships and test BOLA across nested queries and mutations.

Automate BOLA testing in your CI/CD pipeline using frameworks like Dredd, Schemathesis, or custom scripts that generate cross-user access test cases from your OpenAPI specification. Verify that every endpoint returns a 403 or 404 when accessed with a valid token belonging to a different user. Pay particular attention to endpoints that accept arrays of IDs, batch operations, and nested resource paths where authorization might be checked at the parent level but not the child level.