They assume perimeter tools can understand application meaning. In reality, these controls often see only request patterns, not whether a cookie value, body field, or query parameter should match the authenticated identity. BOLA requires contextual authorisation, not just signature matching.
Why This Matters for Security Teams
BOLA, or broken object level authorisation, is a design flaw that appears when an application allows one user to access another user’s object, record, or resource. api gateway and WAFs are still useful, but they do not reliably understand who should be allowed to see which object. That gap is why teams often overestimate perimeter enforcement and underinvest in application-layer authorisation.
The risk is not limited to direct data exposure. BOLA can affect account records, customer profiles, invoices, workflow actions, and non-human identity workflows where a service or agent has broad API reach. Current guidance suggests that request filtering should be treated as a control layer, not a substitute for object-aware authorisation. The NIST Cybersecurity Framework 2.0 reinforces the need to design access controls into the system, not bolt them on at the edge.
Teams also get tripped up by false confidence from allowlists, signatures, and rate limits. Those controls may reduce noise, but they rarely prove that a user can only act on authorised objects. In practice, many security teams encounter BOLA only after a customer reports unexpected cross-account access rather than through intentional testing.
How It Works in Practice
Stopping BOLA requires the application to compare every object reference against the authenticated identity and its authorised scope. That means the API must verify that the user, session, token, or service principal is allowed to access the specific record being requested, not just that the request is syntactically valid. A gateway can forward context, but the decision has to be enforced where the object is resolved.
Effective implementations usually combine several controls:
- Server-side object checks on every read, write, and delete path.
- Scoped tokens and claims that represent tenant, account, or role boundaries.
- Consistent enforcement across REST, GraphQL, and internal service-to-service APIs.
- Audit logging that records subject, object, decision, and reason for denial.
- Negative testing for object swapping, ID enumeration, and parameter tampering.
WAFs and API gateways still add value when they block obvious abuse, normalize traffic, and surface anomalies, but they cannot infer business ownership from a numeric identifier, UUID, or nested JSON field. OWASP guidance on API security and broken object access patterns makes this distinction clear: the control must understand object ownership or delegate that check to the application layer. For teams operating distributed services, that often means pairing gateways with policy checks in code, middleware, or shared authorization services.
This becomes even more important when non-human identities call the API. If an agent, integration, or workload token has broad permissions, the same BOLA failure can expose cross-tenant or cross-environment data at machine speed. The control model must therefore bind both human and non-human access to the objects they are truly authorised to touch. These controls tend to break down in legacy monoliths with inconsistent object ownership logic because the authorization rule is duplicated differently across endpoints.
Common Variations and Edge Cases
Tighter object-level control often increases development and testing overhead, requiring organisations to balance security consistency against delivery speed. That tradeoff is real, especially where teams want to keep gateway rules simple and centralised. But there is no universal standard for treating perimeter policy as sufficient for BOLA; best practice is evolving toward application-enforced decisions with gateway support only as a supplement.
Edge cases are common. Multi-tenant systems need tenant isolation plus object checks. Service meshes may carry identity between services, but they still do not decide whether a user can access a specific invoice or case file. GraphQL can hide object relationships inside nested queries, which makes field-level authorisation and resolver-level checks especially important. In NHI-heavy environments, shared service accounts and automation tokens can blur ownership unless every workload has a narrowly defined trust boundary. Teams that rely on a WAF alone often miss these scenarios because the request looks benign even when the authorisation outcome is wrong. OWASP’s API security guidance and the broader NIST Cybersecurity Framework 2.0 both point toward explicit control design, not assumption-based filtering.
For regulated environments, the practical test is simple: can the system prove object ownership at the point of access, under normal load, across all interfaces, and after a change? If not, BOLA remains a live exposure even when the edge looks hardened.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | BOLA is an access-control failure tied to enforcing who can reach which object. |
| OWASP Agentic AI Top 10 | Agentic and workload identities can amplify BOLA when tokens have broad object reach. | |
| NIST AI RMF | If AI or agent workflows call APIs, governance must cover authorization and misuse risk. | |
| MITRE ATT&CK | T1190 | BOLA can be exploited through exposed applications and API endpoints. |
| OWASP Non-Human Identity Top 10 | Non-human identities often hold the broad API permissions that make BOLA worse. |
Inventory machine identities, narrow scopes, and bind each token to least-privilege object access.
