1. Why BOLA Bypasses Gateways
API gateways excel at verifying authentication (e.g. 'Is this JWT signed by our Auth0 tenant?'). However, they generally lack business context to verify object-level authorization (e.g. 'Does User A have permission to read Invoice #8492 belonging to User B?').
When backend microservices assume that the API gateway has already authorized the request, BOLA vulnerabilities proliferate.
2. Schema Introspection & Query Graphing
If GraphQL introspection is enabled in staging or production, we extract the complete schema AST to map all queries that accept an ID argument (e.g. getAccount(accountId: ID!), getDocument(id: ID!)).
query GetAccountProfile($targetId: ID!) {
account(id: $targetId) {
id
email
billingAddress
internalNotes
subscriptionTier
}
}3. The Dual-Token Authorization Test Matrix
To test systematically, we register two distinct tenant accounts: Tenant A (Attacker) and Tenant B (Victim). We record valid resource IDs belonging to Tenant B, then execute requests using Tenant A's bearer token.
If Tenant A receives Tenant B's private JSON payload with HTTP 200 OK, a high-severity BOLA flaw is verified.
4. Architectural Remediation & Policy Engines
To eliminate BOLA, resolve object permissions directly in the resolver layer using an attribute-based access control (ABAC) or policy engine like Open Policy Agent (OPA).
- Never rely solely on client-supplied IDs without verifying session tenant context.
- Implement centralized data loader policies that check tenancy before fetching rows.
- Disable GraphQL introspection in production environments.
- Enforce automated integration tests that test authorization across multiple tenant tokens.