Introspection queries, depth limiting, cost analysis, field-level authorization, persisted queries, batching attacks, and the unique attack surface GraphQL exposes compared to REST. Bypassing disabled introspection via schema guessing.
GraphQL APIs present a unique security challenge: a single query can traverse deeply nested relationships, request fields with different sensitivity levels, and bypass traditional REST-centric rate limits. Standard web security tooling is often blind to GraphQL-specific attacks like introspection leaks, cost-based denial of service, and batching abuse. This lesson covers how attackers exploit these gaps and how to harden a GraphQL API without breaking its flexibility.
REST APIs have a well-understood security perimeter: each endpoint represents a single resource, and authorisation is checked at the controller level. GraphQL turns this model upside down. A singlePOST /graphql endpoint accepts arbitrary queries that can traverse the entire data graph. The attack surface is no longer a finite list of routes but the entire schema.
The most basic reconnaissance technique is introspection — a built-in GraphQL feature that returns the complete schema definition. An attacker sends query { __schema { types { name } } } and receives every type, field, argument, and relationship the API exposes, including internal fields like passwordHash or isAdmin that were never meant to be queried.
# Attacker discovers the entire schema in one query
query {
__schema {
types {
name
fields {
name
type {
name
}
}
}
}
}
# Response leaks internal types:
# User: id, name, email, passwordHash, isAdmin, internalNotes
# AdminPanel: secretUrl, resetAllPasswords, deleteUserDisabling introspection in production is the first defence, but determined attackers brute-force field names using common patterns (id, name, email, users, admin) and public GraphQL schema registries. Introspection is merely a convenience — its absence does not prevent targeted queries.
Beyond information gathering, GraphQL introduces query-level resource exhaustion. A nested query like posts { comments { author { posts { } } } } triggers a resolver for each field, potentially causing exponential database load. Without depth limiting or cost analysis, a single cheap request can cascade into hundreds of database queries.
Authorisation in GraphQL is fundamentally different from REST. In REST, you check permissions once at the controller level. In GraphQL, a single query hits multiple resolvers, each responsible for a different field. A user might have access to name and email but not passwordHash. Every resolver must independently verify that the requesting user is authorised for that specific field.
Persisted queries offer a stronger defence: instead of sending raw GraphQL, clients send a hash that maps to a pre-registered query on the server. Any ad-hoc query is rejected outright. This prevents attackers from crafting arbitrary queries even if they know the schema.
Batching attacks exploit GraphQL list arguments to query multiple records in a single HTTP request: users(id: [1, 2, 3, 4, 5]) { name email }. A per-request rate limiter sees one request while the server processes five database queries. This technique bypasses naive rate limits and is commonly used for data scraping.
Explore how introspection, depth limiting, and field-level authorisation work in practice. Toggle introspection on and off, try batching attacks, and observe how each layer of defence blocks or permits the query.
Run a query to see the response
No requests yet. Click a preset or write a query to begin.
One of the most damaging GraphQL security incidents in history was the Facebook “View As” bug disclosed in September 2018. Facebook had migrated its mobile API to GraphQL, and the new schema included a ViewAs field that returned the profile as seen by another user. This field was intended for the privacy check feature — letting users verify what their profile looks like to a specific friend.
The critical flaw: the ViewAs resolver did not verify that the requesting user owned the profile being viewed. An attacker could craft a GraphQL query that called ViewAs on any user ID, passing a friend token to bypass the privacy restrictions. Since the resolver only checked whether the viewing user had a friendship relationship — not whether they were the profile owner — it returned private data for any account.
# Attacker's crafted query — Facebook 2018
query stealProfile($targetUserId: ID!, $asUser: ID!) {
profile(userId: $targetUserId) {
name
email
birthday
posts {
content
visibility
}
viewAs(user: $asUser) {
# Returns profile as seen by $asUser —
# but never checks if requestor owns the profile
privateNotes
hiddenPhotos
friendList
}
}
}The breach exposed personal data — including name, email, phone number, birthday, and recent searches — for approximately 30 million Facebook accounts. Attackers used the access tokens they had stolen through a separate credential stuffing attack to authenticate these GraphQL queries, but the root cause was the missing authorisation check in the ViewAs resolver. This incident is a textbook case of how field-level authorisation failures scale in GraphQL: one resolver in a schema of hundreds compromised the entire platform.
Facebook later added an ownership check to the ViewAs resolver and introduced automated security testing that validates every resolver has an authorisation guard. The incident led to wider industry adoption of cost analysis and resolver-level authorisation frameworks for GraphQL APIs.
Securing a GraphQL API requires defence at three layers: the transport layer, the query layer, and the resolver layer. At the transport layer, disable introspection in production, enforce authentication on the endpoint, and apply standard rate limiting per IP and per token.
At the query layer, implement depth limiting to reject queries beyond a configured nesting depth (typically 4–6 levels), and cost analysis to reject queries whose estimated computational cost exceeds a budget. Persisted queries provide the strongest protection by whitelisting allowed queries at build time.
At the resolver layer, every field resolver that accesses the database must check authorisation independently. Use a resolver wrapper or middleware pattern — similar to a REST controller guard — that inspects the field name, the requesting user's role, and the resource owner before returning data.
// Depth limiter — rejects queries deeper than maxDepth
function depthLimit(maxDepth = 5) {
return (resolve: any, _obj: any, _args: any, ctx: any, info: any) => {
const depth = info.path.key === undefined
? 0
: countDepth(info.path, 0);
if (depth > maxDepth) {
throw new GraphQLError(`Query exceeds depth limit of ${maxDepth}`);
}
return resolve();
};
}
function countDepth(path: any, d: number): number {
if (!path.prev) return d;
return countDepth(path.prev, d + 1);
}
// Field-level authorisation resolver wrapper
function requirePermission(permission: string) {
return (resolve: any, _obj: any, _args: any, ctx: any, info: any) => {
const user = ctx.user;
if (!user || !user.permissions.includes(permission)) {
throw new GraphQLError(`Unauthorized: ${permission} required`);
}
return resolve();
};
}
// Cost analysis — each field contributes to a running budget
const FIELD_COSTS: Record<string, number> = {
User: { name: 1, email: 1, passwordHash: 10, friends: 5 },
Post: { content: 1, comments: 4 },
};
const schema = new GraphQLSchema({
query: new GraphQLObjectType({
name: 'Query',
fields: {
users: {
type: new GraphQLList(UserType),
args: { id: { type: GraphQLInt } },
resolve: withCost(5, resolveUsers),
},
passwordHash: {
type: GraphQLString,
resolve: requirePermission('admin:view-passwords')(resolveHash),
},
},
}),
});
// Persisted queries — only registered hashes are accepted
const PERSISTED_QUERIES = new Map([
['abc123', 'query getUser($id: Int!) { user(id: $id) { name email } }'],
['def456', 'query getPosts { posts { title content } }'],
]);
function handleRequest(req: Request): Response {
const hash = req.body.hash;
if (!PERSISTED_QUERIES.has(hash)) {
return new Response(JSON.stringify({
errors: [{ message: 'Query not in registry' }],
}), { status: 400 });
}
// execute the registered query
}1.Which query reveals the entire GraphQL schema, including all types, fields, and relationships?
2.What primary attack does depth limiting protect against in GraphQL APIs?
3.What is the main authorisation challenge in GraphQL compared to REST?