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