Direct answer
Broken object level authorization (BOLA) happens when an API lets a caller access or change an object they are not entitled to use. Test the permission decision for the object and action, using records created by separate authorized test accounts.
Start with an ownership model
For an invoice API, decide who may read an invoice, download its attachment, or change its status. A random identifier can make a record harder to guess, but the server still needs to enforce the permission rule when that identifier arrives.
Reference: OWASP API1:2023 Broken Object Level Authorization.
Create a paired account check
Create one invoice for account A and a different invoice for account B. Record a normal request from each. With permission to test both accounts, check whether A's session can reach B's test record and compare the result against the intended policy.
- Use harmless records whose owner and contents you know.
- Cover read, update, download, and nested resource routes separately.
- Check that shared records remain accessible to their intended collaborators.
Prove the permission failure
A successful HTTP status is insufficient. A response might contain an empty result, a generic page, or A's own data. Evidence should connect the authenticated caller, the specific test object, its owner, the forbidden action, and the data returned or state changed.
- Redact session tokens and customer data from saved requests.
- Record the expected denial as well as the observed response.
- Use an allowed same-owner request as a control.
Retest every route to the object
A fix on the main invoice route can leave the PDF export or a batch route exposed. Add regression cases for the same ownership boundary through each access path. Preserve a positive case so the fix does not block a user from their own invoices.
Assessment limits
Without separate accounts, known record ownership, and an agreed sharing policy, a scanner can identify candidate routes but cannot establish the full authorization boundary. Destructive actions need a disposable fixture and explicit scope.
Frequently asked questions
Are BOLA and IDOR the same thing?
IDOR describes an insecure direct reference to an object. BOLA emphasizes the missing permission decision around an API object. The terminology overlaps, so reports should explain the actual caller, object, and unauthorized action.
Do UUIDs prevent BOLA?
No. Knowing or receiving an object identifier must not give a caller permission to use the object. Unpredictable IDs complement access checks but do not replace them.
Does a 200 response prove BOLA?
No. Verify the response contains the other test account's protected record or that the forbidden state change occurred. Status codes alone do not establish impact.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.