graphql-idor-via-introspection-leak

GraphQL IDOR via Introspection Leak Hunting

What Is Broken and Why

GraphQL resolvers often receive an id argument supplied by the client but fail to verify that the authenticated user owns the referenced object. Authorization is typically implemented at the HTTP middleware layer (REST-style) and never propagated down to individual resolvers — creating a gap when GraphQL is bolted on later. Introspection leaks the full schema, letting an attacker enumerate every query and mutation that accepts an ID argument, then systematically probe each one for missing ownership checks.

Key Signals

• Introspection not disabled — __schema returns data in production
• id arguments typed as ID! or String! with no documented ownership constraint
• Objects expose sensitive fields (PII, tokens, internal metadata) retrievable by bare ID
• App uses Relay global IDs (base64-encoded TypeName:uuid) — trivially enumerable
• Error messages like "Not found" vs "Forbidden" reveal object existence (oracle)
• Batching enabled — can enumerate hundreds of IDs in one request without rate limiting
• Dual-stack architecture (REST + GraphQL) where REST has authz middleware but GraphQL resolvers were added later

Methodology

1. Discover the endpoint — probe /graphql, /api/graphql, /v1/graphql, /gql
2. Run introspection — dump the full schema
3. Identify object types with ID args — look for queries/mutations accepting id, userId, resourceId, ownerId
4. Create two test accounts — Account A (attacker) and Account B (victim)
5. Grab a victim resource ID — note an object ID owned by Account B
6. Query as attacker — from Account A's session, call the resolver with Account B's ID
7. Test mutations too — attempt update, delete, transfer mutations with cross-account IDs
8. Test unauthenticated — remove session token entirely; some resolvers skip auth at the GraphQL layer
9. Confirm impact — verify you can read, modify, or delete data you don't own