Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To test an API for broken object-level authorization (BOLA), send a request as one authorized test account, change only the object identifier to an object belonging to another test account, and check whether the API reveals or changes that object. Repeat across the actions and request types your application supports. The key question is not whether the caller is authenticated or the endpoint works; it is whether that caller may perform that action on that specific object.
Run these checks only on systems you are authorized to test, using designated accounts and data. OWASP’s API1:2023 guidance describes object-level authorization as a code-level check that validates a user’s permission to access particular objects.
What BOLA looks like in an API
An API has a BOLA flaw when a caller can invoke an otherwise available function but the application does not adequately check whether that caller may access the particular object named in the request. The object reference might be in a URL path, query string, header, JSON or form body, or GraphQL variable. It can be a sequential number, UUID, or string; the identifier’s format does not establish permission. See OWASP API1:2023.
For example, a user may be allowed to view their own order at /orders/123. If changing the reference to another user’s order returns its details, the application may be missing an authorization check for that order. The same issue can affect updates and deletions, GraphQL mutations, or requests that accept multiple object IDs. OWASP’s testing guidance also illustrates risks involving records such as revenue data, vehicle controls keyed by VIN, and documents; these are examples of possible impact, not claims about how often such flaws occur. See the OWASP Web Security Testing Guide.
#1 Best Overall
Plan coverage around the object, action, and caller
First define the expected access policy: which users, roles, or tenants may perform which actions on which objects. Then inventory API operations that accept an object reference and act on the object. OWASP recommends object-level checks for every endpoint that receives an object ID and performs an action on it. The identifier may not be obvious from the route: inspect the client’s traffic, API documentation, request headers, payloads, and GraphQL variables. Include list and batch operations as well as nested routes such as a user’s orders. See OWASP API1:2023, the WSTG, and the REST Assessment Cheat Sheet.
| Coverage dimension | Cases to include |
|---|---|
| Object relationship | Own object, another test user’s object, another tenant’s object, and any valid shared or delegated access relationship in scope. |
| Action | Read, create where a parent object is referenced, update, partial update, and delete, as supported by the API. |
| Request shape | Single ID in a path, query, header, or body; nested route; GraphQL variable or mutation; list or batch of IDs. |
| Caller | Each relevant test role or policy relationship, including authorized administrators or tenant members where applicable. |
Use designated test accounts with equivalent objects so the comparison is meaningful. Record the ownership, tenant, or other relationship for each object, and establish what the policy should permit before replaying requests. An object shared legitimately with both accounts is not a valid cross-account denial test.
Run a controlled cross-account swap
- Set the boundary. Confirm written authorization, define the systems and operations in scope, and use only test accounts and data. Agree on expected access rules and how to avoid disruptive changes, particularly for delete operations.
- Prepare two principals and objects. Sign in as account A and account B, then create or select the same type of object under each. Note which account can access each object and which actions the policy allows.
- Capture each baseline. As A, send a normal request for A’s object; repeat as B for B’s object. Preserve the HTTP method, route, relevant headers, body, and authenticated session context. OWASP’s REST guidance recommends using object IDs the other session can already observe, such as IDs exposed in lists or notifications, rather than relying only on guessing.
- Change one object reference. Replay A’s request under A’s session, replacing only A’s object ID with B’s. Keep the method, payload, and other relevant request details unchanged so the object reference is the variable under test. Then test the reverse direction.
- Repeat for each operation and route shape. Test applicable read, update, partial-update, and delete requests, plus nested routes, GraphQL operations, and batch paths. A protected read does not establish that a related write or delete operation is protected.
- Verify outcome and effects. Inspect returned data, then check the object’s state through an authorized test account or other safe verification method. Record the caller, object relationship, action, expected policy, response, and any confirmed side effect.
- Retest after a fix. Add regression cases for each affected action and object relationship. OWASP recommends testing the authorization mechanism and not deploying changes that cause those tests to fail.
Decide whether the result is evidence of BOLA
Strong evidence is that a caller receives another principal’s protected object data or successfully changes an object the caller is not permitted to use. A status code alone is weaker: an API may mask whether an object exists, return a generic response, or use a nonstandard error convention. Compare the result with the stated policy and verify whether the object actually changed. The WSTG and REST Assessment guidance both emphasize testing request outcomes rather than treating an identifier swap or response code by itself as proof.
- Do not label access as BOLA if both accounts are legitimately allowed to use the object under a shared, tenant, delegated, or administrative policy.
- Do not treat an unpredictable UUID as authorization. Random identifiers can make enumeration harder, but OWASP describes them as defense in depth; the application still needs to check permission for the requested object and action.
- Do not assume that a test of one route covers another route that retrieves or modifies the same record. Verify each relevant code path and operation.
Separate BOLA from neighboring authorization flaws
Precise classification helps developers identify which policy check failed. OWASP distinguishes object access from access to a function or to fields within an object.
| Finding | Authorization question | Example |
|---|---|---|
| Broken object-level authorization (BOLA) | May this caller perform this action on this particular object? | A user can call an order-reading function but can retrieve another user’s order by changing its ID. |
| Broken function-level authorization (BFLA) | May this caller use this function or operation at all? | A user can invoke an administrative operation that should be restricted to administrators. |
| Broken object-property-level authorization | May this caller read or change this particular field? | A user can access an otherwise permitted object but can also read or set a restricted property. |
OWASP’s 2023 API Security Top 10 groups excessive data exposure and mass assignment under broken object-property-level authorization. A route can have more than one authorization weakness, so assess object, function, and property boundaries separately.
What to fix when a test fails
Enforce the application’s policy wherever client input selects a record for reading or modification. The authorization decision should consider the authenticated caller, the requested action, the particular object, and the relationships your policy recognizes, such as ownership, tenant membership, delegation, or role grants. A check that only compares the session user ID with one request parameter is not a general solution when legitimate access relationships are more nuanced. Apply checks consistently across the API’s code paths, follow least privilege, and keep regression tests for the cases that exposed the flaw. These principles align with OWASP API1:2023.
Rank #4
Tools can help replay and compare requests
OWASP’s WSTG identifies ZAP, Burp Suite, Postman, and fuzzing tools as aids for sending requests, changing object references, and observing responses. The essential test remains the controlled comparison: preserve the session and request, change the object reference, and verify both the response and any effect. Choose a tool based on your protocol and workflow, and use manual replay when it helps isolate a case or repeatable automation when you need regression coverage. The guidance cited here does not establish current features for any particular tool.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
