Authorization at the Object Level: Testing for BOLA Before Someone Else Does

Broken Object Level Authorization (BOLA) is a top priority issue in API security, yet it often goes unnoticed by automated scanners. This is because BOLA isn't a code defect in the traditional sense. Instead, it's a situation where an API endpoint allows a user to access another user's object, even though the endpoint properly authenticates the user and returns a valid response containing data the user shouldn't see.

The problem often arises when an API takes an object identifier as input and returns the object. The identifier can be sequential, a UUID, or a slug. The key question is whether the API handler verifies that the authenticated user has permission to access that specific object. There are three common variants of this issue: missing check, checking the wrong field, or a bypassable check that only verifies ownership for certain HTTP methods.

Automated scanners struggle to detect BOLA because they don't have multiple identities to compare. They can identify missing authentication, but they can't compare what one identity can see versus another. The best way to test for BOLA is to manually test each endpoint family with two accounts in the same role but different tenants or ownership scopes.

The test involves creating an object with one account and then accessing it with the other account using every method the endpoint supports. A 403 status code is expected, while a 200 status code with data is a finding.

To prevent BOLA, it's best to centralize object-level authorization in a single function that handles every handler that loads an object by identifier. This approach ensures that any future handlers added to the API will also include this crucial authorization check. Additionally, scope queries by the subject, test write paths alongside read paths, and log object identifiers when authorization decisions are made to determine the exposure window of any potential data leaks.