GraphQL Security Testing: A Complete Guide

GraphQL security testing is the assessment of a single GraphQL endpoint for authorization, injection, and denial-of-service flaws expressed through queries and mutations. Because one URL (usually /graphql) fronts the entire data model, the first job is always to recover the schema, and the second is to realize that the OWASP API Security Top 10 still applies, just in GraphQL's syntax.

This guide walks the full process: discovering the schema, testing authorization and mass assignment, abusing GraphQL-specific features like batching and aliasing for DoS and brute force, and the tools that make it practical. Example queries are included throughout.

What is GraphQL security testing?

GraphQL security testing is penetration testing adapted to GraphQL's single-endpoint, client-specified-query model. Instead of dozens of REST routes, you have one endpoint where the client decides exactly which fields and relationships to fetch, which shifts the attack surface toward the schema and the resolver logic behind it.

The discipline overlaps heavily with REST API penetration testing, but three things are unique:

• The schema is the map. Recover it first, by introspection or inference.
• Authorization is per-field and per-resolver, so gaps hide in nested objects.
• Query structure itself is an attack vector: depth, aliasing, and batching.

Everything else (BOLA, mass assignment, injection) is the same risk you would test in REST, reached through a different request shape.

How do you discover a GraphQL schema?

You recover the schema first, ideally through introspection, and fall back to inference when introspection is disabled. The schema tells you every type, query, mutation, and field, which is the entire roadmap for the test.

Start with an introspection query:

POST /graphql HTTP/1.1
Content-Type: application/json

{ "query": "{ __schema { types { name fields { name } } queryType { name } mutationType { name } } }" }

If introspection returns the schema, load it into InQL (a Burp extension) to auto-generate queries. If it is disabled, use Clairvoyance, which reconstructs the schema by abusing the field-suggestion messages in GraphQL error responses ("Did you mean ..."). Run graphw00f first to fingerprint the engine (Apollo, Hasura, graphql-ruby), because each leaks differently and has different default protections.

How do you test authorization in GraphQL?

You test authorization per field and per object, because GraphQL enforces access in resolvers that are easy to forget. BOLA and BFLA are just as common here as in REST; they simply appear inside a query argument or a mutation.

A BOLA in GraphQL looks like passing another user's ID into a query:

POST /graphql
{ "query": "{ user(id: 1052) { email phone ssn } }" }

, - if your token returns user 1052's data, that's a BOLA

Then test nested authorization: a query you are allowed to run may expose a related object you are not, for example { order(id: 9) { customer { email } } } where order is checked but customer is not. For BFLA, call admin-only mutations like mutation { deleteUser(id: 1052) } with a low-privilege token. This per-resolver gap is the most common serious GraphQL finding, mirroring what we cover in the API pentest checklist.

What GraphQL-specific attacks should you test?

Beyond the standard API risks, GraphQL has a native attack surface in query structure: depth, batching, and aliasing. These enable denial of service and rate-limit bypass that REST does not expose.

• Deeply nested queries (DoS): if types reference each other, you can nest a query that explodes the resolver tree, for example { author { posts { author { posts { ... } } } } }. Confirm whether query-depth and cost limits exist.
• Aliasing for brute force: one request can fire hundreds of operations using aliases, bypassing per-request rate limits: { a: login(pw:"1"){token} b: login(pw:"2"){token} ... }.
• Batching: many GraphQL servers accept an array of operations in one HTTP request, again sidestepping rate limits on login or OTP.
• Mass assignment via mutations (BOPLA): pass input fields the client never shows, like { updateUser(input:{id:1, role:"ADMIN"}) { id } }.
• Introspection in production: leaving it enabled is a misconfiguration that hands attackers the full map.

How do you secure a GraphQL API?

You secure GraphQL by enforcing authorization in every resolver, limiting query cost, and disabling introspection in production. The fixes map directly to the attacks above, and most are configuration rather than code rewrites.

• Enforce object and field-level authorization in resolvers, not just at the top-level query.
• Apply query-depth limits, cost analysis, and timeouts to stop nested-query DoS.
• Cap or disable query batching and aliasing on sensitive operations like login.
• Allow-list input fields on mutations to block mass assignment.
• Disable introspection and field suggestions in production to slow schema recovery.
• Apply rate limits per operation, not just per HTTP request, so aliasing cannot bypass them.

Treat GraphQL as a first-class part of your API security program. For continuous coverage across REST and GraphQL together, see how agentic pentesting runs these checks on every deploy.

Frequently asked questions

Sources and references

• OWASP GraphQL Cheat Sheet
• Clairvoyance
• graphw00f