Why do API gateways struggle with broken object level authorisation?

BOLA attacks work because the request often looks structurally correct. A gateway sees a legitimate call, while the abuse happens in the relationship between identifiers, parameters, and application logic. Without deeper context and cross-request analysis, the control has no reliable way to infer that the user is trying to access another object’s data.

Why This Matters for Security Teams

Broken object level authorisation, often called BOLA, is difficult for API gateways because the request itself can look valid while the abuse is hidden in how an object identifier is interpreted by the backend. A gateway is good at checking syntax, tokens, and coarse policy, but it usually cannot infer whether an authenticated user is entitled to access a specific record, tenant, or resource instance. That gap matters because object access failures often become direct data exposure, not just a minor policy miss. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful baseline for thinking about access enforcement and monitoring across layers, but the gateway alone rarely satisfies the intent of those controls.

Security teams often underestimate how quickly BOLA becomes a business issue: customer records, invoices, support tickets, and internal admin objects are all common targets because the application already trusts the identifier passed in the request. The weakness is not usually in authentication. It is in authorization context, ownership checks, and tenant scoping that the gateway cannot reliably see. In practice, many security teams encounter BOLA only after sensitive data has already been retrieved through a perfectly ordinary API call, rather than through intentional abuse detection.

How It Works in Practice

An API gateway sits in front of services and can enforce edge controls such as authentication, rate limiting, schema validation, and coarse route-level authorization. That makes it valuable, but not sufficient. BOLA depends on context that lives deeper in the request path, where the application can compare the requester’s identity, role, session, tenant, and relationship to the specific object being requested.

At a practical level, effective control usually requires the application or a dedicated authorization layer to evaluate ownership and scope on every object lookup. That means the backend must decide whether the caller can read, update, delete, or enumerate the object, rather than assuming the gateway has already done so. Current guidance suggests combining edge policy with service-side authorization and centralized logging so that suspicious access patterns can be correlated across requests. The OWASP API Security Top 10 remains a strong reference for treating BOLA as an application-layer issue, not just an API management problem.

• Validate the caller’s entitlement against the specific object, not just the endpoint.
• Use opaque, non-guessable identifiers where possible, but do not rely on obscurity as the control.
• Enforce tenant boundaries and ownership checks in the service that resolves the object.
• Log object IDs, caller identity, decision outcomes, and repeated access failures for detection.
• Test for horizontal and vertical access bypass during API security reviews and abuse-case testing.

Where gateways help most is in reducing obvious abuse, limiting request volume, and blocking malformed traffic before it reaches the service. Where they fail is in environments with direct object references, shared APIs across tenants, or microservices that trust upstream claims without re-checking authorization because the gateway cannot reliably understand the business relationship between a user and a resource.

Common Variations and Edge Cases

Tighter authorization often increases application complexity and latency, requiring organisations to balance strong object-level checks against developer convenience and service performance. That tradeoff is real, especially in distributed systems where every object fetch may require a policy lookup or relationship graph query. Best practice is evolving, and there is no universal standard for exactly how much logic should remain at the gateway versus in the application.

One common edge case is multi-tenant SaaS, where the same API route serves many customers and object IDs may be predictable enough for enumeration. Another is partner or delegated access, where a user may legitimately view some objects but not others within the same account. In those cases, coarse gateway rules can create false confidence because they cannot express the full business context. The NIST control catalogue is useful for mapping layered enforcement and monitoring expectations, while OWASP Authorization guidance helps teams design checks that are tied to resource ownership rather than route names.

For machine-to-machine APIs, the same issue appears when service accounts or non-human identities are over-privileged and allowed to access objects outside their operational scope. That intersection matters in modern environments where credentials, tokens, and workload identities are reused across services. The practical lesson is that BOLA prevention depends on object-aware authorization and continuous verification, not just perimeter enforcement.

Related resources from NHI Mgmt Group

• What breaks when Broken Object Level Authorization is missed?
• What breaks when REST APIs rely on authentication without object-level authorisation?
• Broken Object-Level Authorization
• What is the difference between scope-based authorization and object-level authorization in MCP?