Contents
Broken Object-Level Authorisation (BOLA) has been the number-one finding in API security work for three years running. In REST APIs it usually shows up as an IDOR — bump the /users/123/profile to /users/124/profile and see what loads.
GraphQL hides the same class of bug behind a different surface. Here’s the test plan I run on every GraphQL engagement.
The pattern
Every GraphQL query that takes an ID — directly or indirectly — is a candidate for BOLA. The interesting cases are the indirect ones: a query that takes a projectId and returns a list of tasks, where each task ends up exposing a creator field with personal details.
The four tests
- Direct ID swap. For every query that takes an ID, try an ID belonging to a different tenant.
- Nested field abuse. Once inside an object, probe every relationship field with arguments that escape the original tenant scope.
- Aliased duplication. Send the same query with two aliases pointing at different tenants in the same request — some authorisation layers cache the first decision and replay it.
- Fragment leakage. Define a fragment that references sensitive fields and inject it into a query that shouldn’t have access to those fields.
Why introspection isn’t enough
Introspection tells you the schema. It does not tell you which fields the authorisation layer actually checks at runtime. That has to be probed.
Burp’s GraphQL extension automates parts of this, but the most interesting BOLA bugs are still the ones that require chaining two or three queries — and that part is still hand work.
Tags