GraphQL Security Testing

In a GraphQL API the client asks for exactly the fields it wants, so the first thing an attacker does is learn what fields exist. Introspection hands that over directly. When introspection is switched off, many servers still leak field names through “did you mean” suggestions in error messages, which is enough to reconstruct the schema query by query. Knowing the shape of the graph is the difference between guessing and going straight for the sensitive resolver.

Because every operation shares a single endpoint, teams often bolt authorization onto the endpoint rather than the resolver. That works until a query reaches a nested field whose resolver assumed the parent already checked permissions. The result is data you can read through one path even though the obvious path is locked. This is the pattern behind most serious GraphQL findings, and it only surfaces when someone tests each field and mutation individually.

We recover the schema first, through introspection where it is enabled and through error-message field suggestions where it is not. The output is a full picture of types, queries, mutations and arguments, which is the map every later test works from.

With the schema in hand we test access control at the resolver level. We call each sensitive query and mutation as an unauthenticated user, then as a low-privilege user, and check whether the object arguments let one account reach another’s data. Batched array inputs get special attention, because a single request that accepts a list of IDs is a common way to loop an IDOR at speed.

GraphQL gives the client power the server has to defend against. We build deeply nested and circular queries to test complexity and depth limits, and we use aliases and query batching to send many operations in one request. Done right, this bypasses rate limits and turns a login form into an offline-speed brute force against your own server.

Injection through resolvers

Arguments in a GraphQL query end up as parameters in database calls, internal HTTP requests and downstream services. We test them for SQL and NoSQL injection, operator injection, and SSRF where a resolver fetches a URL. The query language is just the delivery mechanism; the vulnerability lives in what the resolver does with the value.

You get a report while the findings are current, with each issue proven by a real query and response. After your team fixes, we retest the same operations for free to confirm the resolver now enforces what it should.

Introspection left on in production hands an attacker the entire schema. Turning it off helps, but if error messages still suggest close field names, the schema can be rebuilt anyway. We report both, and we distinguish a genuine leak from introspection that is public by design on an API meant to be open.

The most damaging pattern we see. A mutation that updates or deletes a record checks that you are logged in but never that the record is yours. Because mutations are how GraphQL writes data, a missing ownership check here is not an information leak, it is an attacker editing other people’s accounts.

Object identifiers passed as arguments let you request a specific record. Where the resolver trusts the identifier without an ownership check, incrementing or swapping it returns another user’s data. Array inputs make it worse by letting one query pull a batch of records that were never yours.

Relationships in a graph can be walked in a loop. A query that nests the same relation many levels deep can force the server to resolve an enormous result from a tiny request, exhausting CPU and memory. Without depth and complexity limits, one request is a denial-of-service tool.

Aliases let a single operation contain hundreds of copies of the same query with different arguments. If your throttling counts requests rather than operations, an attacker sends one request and gets hundreds of attempts, which quietly defeats brute-force and enumeration protection.

For SOC 2, testing the API evidences that the controls over customer data are exercised, not assumed. Under GDPR, a broken-authorization query that returns another customer’s records is a reportable exposure, so proving those paths are closed is part of demonstrating appropriate technical measures. Financial-sector clients can fold GraphQL testing into their DORA threat-led testing scope.