attacking-graphql

Attacking GraphQL

GraphQL moves authorization from routes to resolvers, and most teams do not move their access control with it. The REST habit of protecting /admin/* has no equivalent when every operation arrives at one endpoint — so the recurring finding is not an exotic GraphQL bug, it is an ordinary authorization failure on a field nobody thought to guard.

When to Use

• The target exposes /graphql, /graphiql, /v1/graphql, /api/graphql
• Request bodies contain query, mutation, subscription, or operationName
• Responses have the {"data": ..., "errors": [...]} envelope
• A mobile or SPA client posts GraphQL to a backend
• You need to map an API whose schema you do not have

When NOT to Use

• REST or gRPC — use testing-apis or attacking-grpc-protobuf
• Source code available — use auditing-code-for-vulnerabilities; read the resolvers, which is faster and more complete
• The web app around it — use testing-web-applications
• Building a denial-of-service against production — model the risk, prove it minimally, and get explicit authorization before any load

Recover the Schema

# Standard introspection
curl -s https://target/graphql -H 'Content-Type: application/json' \
  -d '{"query":"query{__schema{types{name fields{name args{name type{name}}}}}}"}' | jq .

# Tooling that renders it usefully
graphql-cop -t https://target/graphql
clairvoyance https://target/graphql -o schema.json     # works WITHOUT introspection
graphw00f -t https://target/graphql                    # fingerprint the engine

When introspection is disabled, the schema is usually still recoverable. Most engines return "did you mean" suggestions on a misspelled field, which leaks valid names one character class at a time. clairvoyance automates exactly this.

# Field suggestion leak — the response names fields you did not know
curl -s https://target/graphql -d '{"query":"{ userr { id } }"}' -H 'Content-Type: application/json'
# → "Cannot query field \"userr\" on type \"Query\". Did you mean \"user\"?"