auditing-graphql-attack-surface

Auditing GraphQL attack surface: the schema is the map, the resolver is the guard

A GraphQL API gives the client a query language over your data graph, and with it a set of failure modes a fixed endpoint never had. The client, not the server, decides the shape and depth of each request, so cost is client-controlled. The schema describes every type and field, so leaving introspection open hands an attacker the map. And authorization now lives per field and per resolver, so a check that held at the object level can be skipped one field deeper. Two audits sit here: the surface and cost audit (what the client can see and how expensive it can make a request), and the authorization audit (whether every field and mutation enforces the access its data needs).

When to use

• You are reviewing a GraphQL schema, its resolvers, or a gateway that fronts one.
• The client controls query shape, depth, aliasing, or batching.
• Authorization is enforced in resolvers, per field or per mutation, not only at a route.

Scope check

Audit a GraphQL surface only in systems you own or are authorized to test, with accounts across roles and tenants and permission to send shaped and batched queries. If you can't name the authorization, stop.

The loop

1. Recover the schema and the surface. Determine what the client can learn: is introspection enabled, do field suggestions leak type names on error, is there a published schema? Recover the types, fields, and mutations reachable. The schema is the attacker's map; if it is open, inventory it, and if it is closed, note whether errors still leak it piecemeal.

2. Map query cost to the client. Trace how a query's shape drives work: nested and recursive selections that fan out, a relation that can be walked in a cycle, aliasing that requests the same expensive field many times in one query, and connection fields with no page bound. The client chooses depth and repetition, so the ceiling on cost is whatever the server does not cap.