Static reviews miss BOLA because the logic looks correct in code.
Authorization is verifiable only by exercising request paths with real credentials.
Real validation means cross-tenant object access and state-dependent checks.
Autonomous validation supplies the scale and evidence microservices demand.
Here is an uncomfortable fact for anyone who has shipped a static authorization review as a compliance checkbox: the most dangerous AuthZ bugs are invisible in the code.
Broken Object Level Authorization has topped the OWASP API Security list for good reason. And BOLA is, almost by definition, a bug a code review will not find.
The invisible nature of authorization bugs
The authorization logic is correct. The @RequireRole decorator is present. The middleware checks a session. Everything a static reviewer looks at passes.
That gap only becomes observable when you actually call the endpoint with the wrong user's token against the right object's ID.
Structural limitations of code reviews
A binary, structural question about the shape of the code — answerable by reading it.
A behavioral question about a running system. Only a real request can settle it.
Modern applications have hundreds of object relationships. A single missed scope check on any one of them, on any one endpoint, is a BOLA vulnerability.
Multiply that across a microservices architecture with dozens of services, each implementing its own authorization logic slightly differently, and you get a surface area no manual review realistically covers. This is why authorization is fundamentally a runtime property: it can only be verified by exercising the actual request path with real credentials against real objects, and observing the real response.
The mechanics of runtime authorization testing
Effective validation means systematically attempting the thing a code reviewer cannot: cross-tenant object access. For every discoverable object ID and every authenticated identity — does the API return data it should not?
Cross-tenant object access
Enumerate discoverable object IDs and replay them against every authenticated identity. The only acceptable result is a denial.
Privilege boundary testing
Can a lower-privileged role reach an endpoint or field gated to a higher-privileged one, through a parameter the client controls?
Vertical and horizontal escalation
Not just “can User A see User B's data,” but “can Org A's service account act on Org B's resources through an indirect object reference.”
State-dependent authorization
Checks that pass at object creation but are never re-evaluated after an ownership transfer, a role change, or a subscription downgrade.
Doing this manually — endpoint by endpoint, object by object, across every release — is not something a human appsec team can sustain at the velocity modern engineering ships.
From findings to actionable evidence
The output that moves an engineering team is not “endpoint X might have an AuthZ issue.” It is this:
Using Account A's session token, we retrieved Account B's invoice by incrementing the ID. Here is the request, here is the response, and here is the exact line where the ownership check is missing. That is a bug an engineer fixes in an afternoon, because there is no ambiguity about whether it is real.
Validating behavior over intent
Appsec programs that still gate authorization assurance on a point-in-time code review are validating the wrong artifact. Code review confirms intent. Runtime validation confirms behavior — and behavior is what an attacker actually interacts with.
| Dimension | Static AuthZ review | Runtime validation |
|---|---|---|
| Artifact validated | The code as written — intent. | The running application — behavior. |
| Question answered | Does a check exist on this path? | Does the check scope access to the correct object, for this identity? |
| BOLA coverage | Structurally blind: correct-looking logic passes. | Every object relationship exercised with real credentials. |
| Output | “Review authorization logic on endpoint X.” | Request, response, and the missing check's exact location. |
| Cadence | Point-in-time, at design or audit time. | Continuous — run against every release. |
Continuous, evidence-driven validation — run against every release rather than once at design time — is what closes the gap between “we reviewed the AuthZ logic” and “we proved the AuthZ logic holds, this week, against this build.”
Ship the review. Then validate the runtime. The second one is where the real bugs live.
Glossary of terms
Broken Object Level Authorization — an endpoint authenticates the caller but fails to confirm the caller owns the specific object requested.
A client-supplied identifier that resolves to a resource on the server, allowing access to be steered by changing a parameter.
Replaying requests for one tenant's objects using another tenant's credentials to confirm isolation holds.
Reaching a peer identity's data at the same privilege level — User A retrieving User B's records.
Reaching an endpoint, field, or action gated to a higher-privileged role than the one held.
Access decisions that must be re-evaluated after ownership transfers, role changes, or plan downgrades — and often are not.
A behavior only observable while the system runs, and therefore unverifiable by reading source alone.
Validate authorization against your running application.
Hayrok maps API surfaces, generates multi-tenant test identities, and safely attempts object-, function-, and tenant-level bypasses — returning validated proof with the request, the response, and the missing check.
Dan Aoki · Hayrok's Bumblebee
Practical guidance for evidence-driven security validation. Field notes from the hive.