Because BOLA depends on whether a caller is entitled to a specific object at a specific moment, not just whether code looks unsafe or a live request succeeds. SAST cannot observe runtime entitlement, and DAST often lacks enough discovery and workflow context to exercise the exact access path. The failure is contextual, so the test must be contextual too.
Why Contextual Access Checks Escape Static and Dynamic Testing
Broken object-level authorisation is missed when teams assume a safe code pattern or a successful test transaction proves access is correct. SAST is good at finding unsafe constructs, but it cannot confirm whether an authenticated caller should reach a specific object in a specific business state. DAST can see the request and response, yet it often lacks the role setup, object discovery, tenant context, or workflow sequence needed to probe the exact boundary where authorisation fails. NIST’s control families treat access enforcement as an operational control, not a source-code property, which is why the weakness persists when testing focuses too narrowly on syntax or a single happy path. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because object-level access control depends on consistent enforcement, not just testable request shape. In practice, many teams discover BOLA only after a legitimate workflow exposes a neighbouring object that the test suite never tried to enumerate.
How SAST and DAST Miss the Real Access Boundary
SAST sees code, not entitlement. It can identify patterns such as direct object references, weak parameter handling, or missing checks in a function, but it cannot prove whether the surrounding application layer enforces ownership, tenancy, role scope, or policy decisions at runtime. A code path may look risky and still be protected by middleware or service-side checks; the reverse is also true, where the code looks ordinary but the authorisation decision is missing in a different layer. That is why SAST findings around BOLA are often suggestive rather than definitive.
DAST has the opposite limitation. It interacts with the live application, so it can confirm whether a request succeeds, but it usually tests only the access paths it can discover and the identities it can impersonate. If the scanner lacks alternate users, object identifiers, business workflow state, or prior steps needed to unlock an object, it may never exercise the failing boundary. Even when it does, a single success or failure does not prove the broader control is sound.
- SAST is blind to runtime identity, session, and state-dependent checks.
- DAST is blind to undiscovered object paths and business-context prerequisites.
- Both tools can miss errors when authorisation is split across services, APIs, and front-end flows.
- Neither tool replaces tests that compare one caller’s entitlement against another caller’s access to the same object.
That limitation is especially sharp in multi-tenant systems, object-rich APIs, and workflows where access depends on ownership, team membership, or approval state. The guidance breaks down where object identity is hidden behind indirect references, asynchronous processes, or layered enforcement that scanners cannot faithfully reconstruct.
Where BOLA Testing Gets Distorted by Workflow, Tenancy, and State
Tighter object-level testing often increases test maintenance, requiring organisations to balance coverage against the overhead of modelling users, objects, and workflows correctly. The edge cases matter because BOLA is rarely just “missing auth” in the abstract; it is usually a mismatch between a caller’s scope and the exact object the system is willing to return. That mismatch can vary by tenant, by role, by object lifecycle, or by whether the object was created, shared, transferred, or archived.
One common consensus point is that teams should not rely on URL structure or hidden identifiers as evidence of protection. There is also broad agreement that positive and negative tests must be paired, but there is less consensus on how much business-process modelling belongs in security testing versus application testing. For BOLA, that boundary is blurred in practice, because the security failure is often inseparable from the workflow that exposes the object in the first place.
Another edge case is API aggregation. A front-end request may look harmless while a downstream service returns a sensitive object because it trusts the upstream caller too much. In those cases, scanner coverage can look healthy while the actual object boundary remains untested. The most reliable assumption to challenge is that “authenticated” means “authorised”; BOLA failures are usually built on that false equivalence.
Risk and Threat Considerations
Broken object-level authorisation creates direct exposure of data and actions that should be limited to a different user, tenant, or role. The risk is not just disclosure; it can also include modification, deletion, workflow manipulation, or privilege-in-the-business-process even when authentication itself is intact.
Failure mechanism: The weakness materialises when the application trusts a caller’s session or request shape but does not re-check entitlement for the specific object being accessed. Attackers and curious insiders can then enumerate identifiers, replay legitimate requests against adjacent records, or abuse poorly modelled workflow transitions to reach objects outside their scope.
Impact: Sensitive records can be exposed or altered across tenant and role boundaries, audit confidence declines, and downstream systems may propagate the wrong data or state. At scale, a single missed access control path can affect many objects, not just one endpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | BOLA is an object-level access control failure that CIS Control 6 is designed to prevent. |
| Recommendation — Enforce object-level access rules and review them against real user and tenant scenarios. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The issue is a mismatch between authentication and object-level authorisation enforcement. |
| Recommendation — Validate that authenticated identities are authorised for each object before access is granted. | ||
| MITRE ATT&CK | T1069 — Permission Groups Discovery | BOLA exploitation often depends on discovering object scope and access differences. |
| Recommendation — Hunt for discovery and abuse patterns that reveal which objects a caller can reach. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Authorization and Scope Management | Object-level authorisation failures often expose overbroad non-human or service access paths. |
| Recommendation — Constrain machine and service access to the smallest object scope required. | ||
Practitioner Guidance
What to verify: Test authorisation as a matrix, not as a single request outcome. The key question is whether two different callers can reach the same object under the same circumstances, and whether the denied case is enforced after every relevant workflow step, not only at the edge.
What practitioners underestimate: Discovery is part of the test. If the object cannot be enumerated, selected, or reached through a realistic workflow, DAST may report clean results that simply reflect incomplete coverage. Teams should treat missing object discovery as a testing gap, not as proof of safety.
Practitioner takeaway: BOLA is most often missed when security testing validates requests instead of entitlements, so the control question should always be “who can act on which object, in which state, and through which path?”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
