GraphQL Abuse

GraphQL gives the client one endpoint and a lot of power: it asks for exactly the fields it wants, can describe its own schema, and can run many operations in a single request. Each of those conveniences is also an attack surface. The vulnerabilities are rarely GraphQL-specific bugs — they are the classic ones (information disclosure, broken authorization, missing rate limits) wearing a GraphQL shape.

What is the vulnerability?

• Introspection left on. Any client can ask __schema for every type and field, mapping operations the UI never shows — including ones the developer assumed were hidden.
• Missing object authorization. A user(id) resolver returns the record for that id without checking you own it. Change the id, read anyone — IDOR through a query.
• Alias batching. GraphQL runs many fields per request. If a rate limiter counts requests, one request can alias a sensitive field a hundred times and sail past the limit.

Why does it happen?

GraphQL moves work the REST world spread across many endpoints into one flexible query, so per-endpoint habits — “this route is internal”, “rate-limit this URL” — stop mapping cleanly. Authorization has to live on every field resolver, and limits have to be about query cost, not request count.

How do you stop it?

Disable introspection in production. Put an authorization check in every resolver that returns private data — never trust an id argument. Limit by query complexity, depth and repeated-field count, so one request cannot hide a hundred attempts.

The three labs below walk this: discover a hidden field, read another user through user(id), and brute-force a code with aliases in one request.