'm participating in several bug bounty programs, but I'm struggling with GraphQL. Specifically, I want to find Insecure Direct Object References (IDOR). Since GraphQL uses a single endpoint, how do you map out the objects and find where authorization checks might be missing?
3 answers
Hunting in GraphQL starts with "Introspection." If the developer hasn't disabled it, you can query the __schema to get a full map of every query and mutation available. Once you have the map, look for queries that take an ID or UUID as an argument, such as getUser(id: "123"). The trick for IDOR is to try and access an ID that doesn't belong to your session. Since many GraphQL apps use incremental IDs or predictable UUIDs, you can use Burp Intruder to cycle through them. Always check both "Queries" (fetching data) and "Mutations" (changing data), as authorization is often missed in the latter.
Introspection is usually disabled in production environments. What are your go-to methods for mapping the schema when the __schema query returns an error?
Also, look for "Nested Queries." Sometimes a top-level query is secure, but a nested object inside it lacks the proper authorization checks, leading to a massive data leak.
Ralph is spot on. "Object Level Authorization" is the most common failure in complex GraphQL schemas with many relationships.
If introspection is off, you have to rely on "Field Suggestion" attacks. Many GraphQL engines will suggest the correct field name if you make a typo, like "Did you mean 'users'?". Tools like Clairvoyance or InQL can automate this "guessing" process to reconstruct the schema bit by bit. It's much more tedious than introspection, but it often reveals hidden administrative queries that the developers thought were safe because they weren't documented in the front-end code.