Teams should test every endpoint that accepts an object identifier with both authorized and unauthorized roles, then verify that the server enforces the correct outcome at runtime. The goal is not just functional access but negative testing for denial, because BOLA lives in the gap between a valid request and an invalid entitlement.
Test the identifier path, not just the happy path
When an API exposes an object identifier, the testing question is whether the server treats that identifier as sufficient proof of entitlement. Endpoints often appear to work correctly for the caller’s own records while failing open for another user’s record, so the test must compare the same request across authorized and unauthorized contexts and confirm the runtime decision, not just the response shape.
The highest-value test cases are the ones where the identifier is valid but the entitlement is wrong. That means you should vary role, tenant, ownership, and object scope while keeping the request syntactically correct. A good test matrix also includes alternate verbs and adjacent endpoints, because object-level authorization failures often show up in one route or method while a related route remains unprotected.
For APIs that expose identifiers in URLs, bodies, or query strings, the identifier should be treated as untrusted input until authorization is re-evaluated on the server side. If the endpoint only checks that the object exists, or only checks that the caller is authenticated, the control is incomplete. OWASP API Security Top 10 is the clearest external reference for this failure mode because it frames broken object-level authorization as a core API risk, not an edge case.
How to structure negative authorization tests
Start by identifying every endpoint that accepts an object identifier and mapping which object types it can reach. Then test at least one positive case, one clearly unauthorized case, and one same-scope but different-owner case for each object family. The goal is to prove the server enforces the right entitlement at the point of access, even when the request is well formed.
Use more than one unauthorized persona where possible. A low-privilege authenticated user, a different tenant user, and a user with a similar role but different object scope can each expose different authorization mistakes. This matters because many BOLA defects are not universal bypasses, they are inconsistent checks, such as owner-only logic on one endpoint and role-only logic on another.
Testing should also cover identifier tampering, predictable IDs, enumeration, and object references buried in nested JSON. If a caller can swap an identifier and still receive data or trigger a state change, that is evidence the access decision is not bound tightly enough to the object. If the API returns generic errors, verify the status code and side effects as well, because an implementation can hide the object but still leak existence or permit mutation.
What good authorization evidence looks like
Strong evidence is not a single denied request. It is a repeatable set of results that shows the server makes the same allow or deny decision regardless of how the object identifier is supplied, and that the decision changes appropriately when the caller’s entitlement changes. For this reason, test evidence should include the request, the caller context, the expected rule, and the observed runtime outcome.
When the endpoint is part of a broader access model, the object test should align with the governing authorization pattern, whether that is role-based, attribute-based, relationship-based, or policy-driven. Authorisation Models Guide is useful here because it helps teams decide whether the object decision is role-scoped, attribute-scoped, or relationship-scoped before they build the test suite. A separate access model can also clarify why a request should be denied even when the caller is otherwise authenticated.
For teams that need a practical API testing method, OWASP Web Security Testing Guide provides a structured way to turn authorization expectations into test cases and negative assertions. That is especially helpful when multiple services expose the same object type and each one must enforce the same entitlement boundary.
Risk and Threat Considerations
Broken object-level authorization is dangerous because the object identifier often becomes a direct attack surface. If the server trusts the identifier more than the caller’s entitlement, an attacker can move from one valid request to unauthorized reads, updates, or deletion, often without needing to defeat authentication at all.
Failure mechanism: The application accepts a legitimate object identifier but fails to bind the access decision to ownership, tenant scope, role, or policy at runtime. That creates a gap where a syntactically valid request can produce an unauthorized result.
Impact: The result can be cross-account data exposure, unauthorized state change, privilege abuse, and large-scale enumeration if identifiers are guessable or sequential. In API-heavy systems, the same flaw can affect many endpoints at once, making the blast radius much larger than a single broken route.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | API endpoints exposing object IDs are the core BOLA testing case. |
| Recommendation — Test every object-bearing endpoint for allow and deny outcomes across ownership and role boundaries. | ||
| OWASP ASVS | V8 — Authorization | The question is about verifying authorization decisions on API object access. |
| Recommendation — Verify object access against server-side authorization checks, not client-supplied identifiers. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Unauthorized object access exposes excessive privilege or missing entitlement checks. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Negative authorization tests need evidence that denials and failures are observable. | |
| Recommendation — Limit object actions to the minimum entitlements needed for each caller role. Review logs for denied object-access attempts and unexpected authorization success. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Object-level authorization testing supports validation of enforced access boundaries. |
| Recommendation — Validate and periodically test access rules for all object-bearing API endpoints. | ||
Practitioner Guidance
What to verify: Confirm that authorization is checked on every object access, not just on entry to the API or after the object has already been loaded. The control should be evaluated against the caller, the object, and the action together.
Decision rule: If a test only proves that a request was authenticated, treat it as incomplete. If a test proves the same object is denied to an unauthorized role and allowed to an entitled role, you have evidence that the runtime decision is actually object-aware.
Common mistake: Teams often test only the happy path for their own account and assume authorization is correct because the endpoint returns data as expected. That misses the exact failure mode BOLA relies on, which is a valid request carrying an invalid entitlement.
Practitioner takeaway: Authorization testing for object identifiers should prove that the server denies the right object to the wrong caller every time, because that is what separates a protected API from one that merely looks protected.
Related resources from NHI Mgmt Group
- How should security teams test API endpoints for Broken Object Level Authorization before release?
- How should teams structure API test cases for security-critical endpoints?
- How should security teams test API authorization in fast-changing environments?
- How should security teams implement object-level authorization in APIs that expose user or account data?