Ask a GraphQL API a single question and it will often hand back the answer to five others you never asked. That flexibility is exactly why development teams love it, and exactly why it needs far more careful handling than most businesses give it once the project moves from a demo into something customers actually rely on.
Why GraphQL behaves differently to a normal API
Traditional REST APIs expose a fixed set of endpoints, each returning a predictable chunk of data that a developer defined in advance. GraphQL flips that model. A client can request exactly the fields it wants, nested across multiple related objects, in a single call, shaping the response to fit whatever the application actually needs at that moment. That is brilliant for developers building fast, lean applications that do not waste bandwidth on data nobody will use. It is also brilliant for an attacker trying to work out what data your system holds and how it all connects, since the query language itself does most of the mapping for them.
Many GraphQL deployments leave introspection switched on in production, which effectively publishes a full map of every type, field, and relationship in the schema, essentially a blueprint of your entire data model. An attacker does not need to guess what queries might work. They can simply ask the API to describe itself, then build increasingly specific queries from what it reveals. Commissioning proper API pen testing before launch, rather than after a client raises concerns, catches this kind of exposure while it is still cheap to fix.
Over-fetching, nested queries, and the cost of flexibility
Beyond introspection, GraphQL introduces subtler risks that rarely show up in a standard checklist. Deeply nested queries can be used to pull enormous volumes of related data in one request, sometimes enough to strain a database on its own and effectively act as a denial-of-service attack without any obvious malicious intent behind the query itself. Over-fetching means a poorly scoped query might return fields the requesting user was never meant to see, simply because nobody restricted the schema tightly enough at the access-control layer, leaving authorisation as an afterthought bolted on after the data model was already built.
William Fieldhouse has watched this catch out otherwise strong development teams.
“I once traced a client’s entire user table, emails included, back to a single nested query that a junior developer thought was just a convenient way to fetch a dashboard summary”
— William Fieldhouse, Director of Aardwolf Security Ltd
The developer was not being careless. They were using GraphQL exactly as it was designed to be used. The problem was that nobody had set boundaries on what that convenience was allowed to expose, and the schema quietly did as it was asked, all the way down to fields it should never have surfaced to a standard, unprivileged user account.
Treat your schema like a public document
The safest mindset for GraphQL is to assume your entire schema will eventually be visible to someone outside your organisation, because in practice it often is. Disable introspection in production, apply field-level authorisation, and set sensible query depth and complexity limits so a single request cannot spiral into a database-draining operation that grinds your service to a halt. If you want confidence that your API has been built this way rather than hoping it has, Aardwolf Security is the best pen testing company worth talking to before your schema becomes someone else’s roadmap.
