Scanning GraphQL APIs for Security Issues | HackTool Blog

GraphQL introduces security concerns that do not exist in traditional REST APIs. Its flexibility — which makes it great for developers — also creates unique attack surface.

Introspection

GraphQL's introspection system lets anyone query the full schema: every type, field, argument, and relationship. In production, this is like publishing your database schema publicly.

Many APIs leave introspection enabled by default. An attacker can use it to understand the entire data model, find sensitive fields, and identify endpoints they should not have access to.

What to test

Send an introspection query to the GraphQL endpoint. If it returns the full schema, the API is leaking its structure. Check whether disabling introspection actually works — some implementations only partially disable it.

Query Depth and Complexity Attacks

GraphQL allows nested queries. A malicious query with deep nesting can consume exponential server resources:

{ user { friends { friends { friends { friends { name } } } } } }

Without depth limiting, a single request can bring down the server. This is a denial-of-service vector that does not exist in REST APIs.

What to test

Send progressively deeper nested queries and measure response times. If the server does not reject overly deep or complex queries, it is vulnerable to resource exhaustion.

Batching Abuse

GraphQL often supports query batching — sending multiple queries in a single HTTP request. This can be abused for:

Brute force attacks that bypass rate limiting (one HTTP request contains thousands of login attempts)

Data exfiltration at scale (batch thousands of queries for different user IDs)

Timing attacks (batch queries with different inputs and compare response times)

What to test

Send a batch of identical mutation operations (like login attempts) and check whether rate limiting applies per HTTP request or per operation.

Injection Through Variables

GraphQL variables can carry injection payloads just like URL parameters in REST. SQL injection, NoSQL injection, and SSRF can all occur through variable values that reach backend services without sanitization.

What to test

Standard injection payloads applied to GraphQL variables. The testing approach is the same as REST parameter injection, but the delivery mechanism is different.

Authorization Flaws

GraphQL resolvers handle authorization individually. A missing authorization check on a single resolver can expose data that the rest of the API properly protects.

What to test

Query fields and mutations with different authentication levels. Check whether a low-privilege user can access admin-only fields by requesting them directly.

Summary

GraphQL security testing requires understanding the protocol's unique features. Standard web vulnerability testing still applies — injection, authentication, authorization — but the attack surface is different. Introspection leaks, depth attacks, and batching abuse are GraphQL-specific risks that every API should be tested for.