GraphQL APIs power modern applications from GitHub to Shopify, handling millions of requests daily. A single security flaw can expose entire databases, enable unauthorized data access, or allow attackers to overload servers. Most developers implement GraphQL without understanding its unique security challenges.
Why GraphQL Security Differs From REST APIs
GraphQL fundamentally changes how clients interact with APIs. Unlike REST endpoints returning fixed data structures, GraphQL uses a single endpoint accepting infinite query variations. This creates security challenges that don't exist in REST.
Schema Exposure Through Introspection
GraphQL exposes your entire schema through introspection queries. Attackers discover all queries, mutations, and data relationships without documentation. According to the GraphQL Foundation Security Working Group, introspection represents one of the most exploited features in production environments. REST APIs hide endpoint structures, while GraphQL reveals everything by default.
Unlimited Query Complexity
Query depth in GraphQL enables attackers to craft malicious queries that exponentially increase server load:
{
users {
posts {
comments {
author {
posts {
comments {
# continues 20+ levels deep
}
}
}
}
}
}
}
REST APIs limit responses through predefined endpoints. GraphQL requires explicit depth and complexity controls.
Field-Level Authorization Requirements
REST secures entire endpoints. GraphQL demands field-level authorization. An authenticated user accessing a user profile shouldn't see internal notes or admin-only fields, but GraphQL returns all requested fields if the top-level query succeeds without field-level controls.
Critical GraphQL Security Vulnerabilities
Introspection Enabled in Production
Introspection queries allow anyone to download your complete schema:
query {
__schema {
types {
name
fields {
name
}
}
}
}
Production APIs must reject this query. Major companies have exposed internal data structures through enabled introspection, giving attackers complete maps of available data and operations.
Apollo Suggestions and Schema Leakage Without Introspection
Disabling introspection doesn't fully close the schema exposure window. Apollo Server and several other GraphQL implementations enable "query suggestions" by default error responses that helpfully suggest the correct field name when a query references a non-existent one:
{
"errors": [{
"message": "Cannot query field 'usr' on type 'Query'. Did you mean 'user'?"
}]
}
Here are the ways attackers use this to reconstruct your schema without ever running an introspection query: they submit deliberately misspelled field names, collect the suggestion responses, and iteratively map your entire type system queries, mutations, arguments, and relationships one error message at a time. This technique bypasses introspection-disabled protections entirely and is one of the more underappreciated GraphQL vulnerabilities in production environments.
APIsec detects Apollo suggestion leakage automatically by probing for error-based field enumeration across your schema. It identifies whether suggestions are enabled and flags schema leakage risk, even when introspection is explicitly disabled, a gap that most graphql api security tools miss entirely.
Deeply Nested Query Attacks
Without depth limiting, attackers create exponentially complex queries. Each nesting level multiplies database operations. A query with 10 levels requesting 10 items per level executes 10 billion operations. In 2020, a researcher crashed a production GraphQL API using deeply nested queries, causing three-hour outages.
Missing Field-Level Authorization
Many implementations check authorization only at the query level. This represents a broken object-level authorization (BOLA) vulnerability. An authenticated user might query another user's profile and include sensitive fields like social security numbers or credit card details in their request. Without field-level authorization, the API returns all requested data regardless of the requester's permissions.
IDOR and BOLA via GraphQL Argument Manipulation
Field-level authorization failures in GraphQL go deeper than returning wrong fields; they extend to argument-level access control, where the vulnerability lives inside the query arguments themselves. This is where GraphQL injection and object-level authorization failures intersect. Here are the ways argument manipulation enables BOLA in practice:
- An attacker authenticated as User A substitutes User B's identifier directly into a query argument, for example, swapping their own userId for another user's in a userOrders query
- If the resolver validates authentication but not object-level ownership, User B's payment method, shipping address, and order history are returned to User A
- The same pattern extends to mutations, where an attacker passes an admin user ID into an updateProfile mutation to overwrite another account's details entirely
A vulnerable resolver checks only that the user is logged in, never that they own the target resource:
javascript
const resolvers = {
Mutation: {
updateProfile: async (_, { userId, email }, context) => {
if (!context.user) throw new Error('Unauthenticated');
// Missing: ownership check
return db.users.update({ where: { id: userId }, data: { email } });
}
}
};
A correctly hardened resolver enforces object-level ownership before executing:
javascript
const resolvers = {
Mutation: {
updateProfile: async (_, { userId, email }, context) => {
if (!context.user) throw new Error('Unauthenticated');
if (context.user.id !== userId) throw new Error('Unauthorized');
return db.users.update({ where: { id: userId }, data: { email } });
}
}
};
APIsec detects BOLA via argument manipulation by systematically substituting resource identifiers across authenticated sessions, testing whether the resolver enforces object-level ownership checks on every argument, not just the top-level query gate. This aligns directly with the OWASP GraphQL Cheat Sheet guidance on per-object authorization enforcement.
Deeply Nested Query Attacks
Without depth limiting, attackers create exponentially complex queries. Each nesting level multiplies database operations. A query with 10 levels requesting 10 items per level executes 10 billion operations. In 2020, a researcher crashed a production GraphQL API using deeply nested queries, causing three-hour outages.
Missing Field-Level Authorization
Many implementations check authorization only at the query level. This represents a broken object-level authorization (BOLA) vulnerability. An authenticated user might query another user's profile and include sensitive fields like social security numbers or credit card details in their request. Without field-level authorization, the API returns all requested data regardless of the requester's permissions.
SQL Injection Through Variables
GraphQL variables can carry SQL injection payloads when resolvers concatenate input directly into database queries:
// Vulnerable resolver
const resolvers = {
Query: {
users: (parent, { namePrefix }) => {
return db.query(`SELECT * FROM users WHERE name LIKE '${namePrefix}%'`);
}
}
};
Attackers pass specially crafted strings like ' OR '1'='1 through variables. Understanding business logic vulnerabilities helps identify these injection points.
Batch Query Attacks
GraphQL supports query batching. Attackers exploit this by batching hundreds of expensive queries in a single HTTP request, bypassing rate limits. Traditional rate limiting counts HTTP requests, not GraphQL operations. A single HTTP request containing 100 batched queries appears as one request to standard rate limiters.
Alias-Based Brute Force and Rate Limit Bypass
Batch queries aren't the only way attackers bypass rate limiting in GraphQL. Alias-based attacks achieve the same result within a single operation, making them significantly harder to detect with standard controls. An attacker sends a single mutation containing dozens of aliased login attempts, each executing independently on the server:
graphql
mutation AliasedBruteForce {
a1: login(username: "victim@co.com", password: "Password1!") { token }
a2: login(username: "victim@co.com", password: "Password2!") { token }
a3: login(username: "victim@co.com", password: "Password3!") { token }
# continues to a100+
}
Standard rate limiters see one HTTP request and one GraphQL operation while the server processes over a hundred credential attempts simultaneously. Here are the ways this attack pattern causes damage beyond simple login brute force:
- OTP verification endpoints are equally exposed, and six-digit codes can be brute forced across batches within a single request window
- Password reset flows that accept aliased verification attempts can be exhausted without triggering per-request rate limits
- The attack leaves a minimal footprint in access logs since it appears as a single operation
The distinction from batch queries matters for defense. Batch limits restrict the number of operations in an array, while alias limits restrict aliased fields within a single operation most implementations enforce one without the other. APIsec tests for operation-level abuse specifically, identifying alias-based rate limit bypass separately from batch abuse, and flags endpoints where neither control is enforced.
GraphQL Penetration Testing Methods
Discovering GraphQL Endpoints
Test common endpoint patterns with universal queries. Valid GraphQL endpoints recognize the query { __typename }and return structured responses.
Testing Introspection Controls
Submit introspection queries requesting schema information. Production APIs should reject these queries with clear error messages stating "GraphQL introspection is not allowed." Accepted introspection queries expose your complete schema structure.
Testing Query Depth Limits
Submit progressively deeper nested queries (5, 10, 15, 20+ levels). Monitor server response times and verify queries are rejected before execution, not after consuming resources. Proper depth limits return error messages before touching the database.
Testing Field-Level Authorization
Authenticate as a low-privilege user and attempt to access restricted fields. Request user profiles including sensitive fields like API keys, internal notes, payment methods, or admin-only data. Successful responses indicate missing field-level authorization.
Testing Batch Query Limits
Send batched queries with 50-100 operations in a single request. Proper protection counts total operations and enforces maximum batch size limits.
Testing Operation Limits and Query Size Constraints
Batch size is one dimension of operation abuse, but comprehensive GraphQL security testing should validate the full range of operation limits that protect against resource exhaustion.
Here are the ways these limits should be tested and what APIsec automates across each:
- Max root fields an unbounded query with 50 aliased root fields executes 50 parallel resolver chains simultaneously. APIsec tests whether the server enforces a root field ceiling and rejects queries that exceed it
- Max aliases per operation, separate from batch limits, APIsec verifies that alias counts within a single operation are bounded independently of batch controls
- Unique field limits the same expensive field requested repeatedly under different aliases multiplies resolver execution without triggering depth or complexity limits. APIsec tests whether duplicate field resolution is bounded
- Query size in bytes the simplest limit to enforce and the most commonly missing. Without it, all depth, complexity, and alias controls can be circumvented with verbose but shallow queries
APIsec submits progressively larger query payloads to identify whether a byte ceiling exists and flags its absence as a critical gap. These four checks run on every schema version, ensuring operation limits don't silently regress when new fields or mutations are added to the schema.
Testing Input Validation
Test variables with malicious payloads, including SQL injection strings, XSS payloads, command injection attempts, and oversized inputs. Submit special characters, extremely long strings, and format-breaking characters. Implement continuous testing throughout development.
Testing CSRF Over GraphQL
Cross-Site Request Forgery is frequently overlooked in GraphQL security assessments because developers assume JSON-only APIs are CSRF-immune. That assumption breaks down in two specific scenarios that GraphQL pentesting must explicitly validate. Here are the ways CSRF exploits GraphQL APIs in practice:
- GET-based GraphQL abuse occurs when a server accepts queries via GET requests, an attacker embeds a mutation URL in an img tag or a malicious page. The browser automatically attaches the victim's session cookies when loading it, executing the mutation without any user interaction
- Content-type bypass CSRF protection often relies on browsers not being able to send application/json cross-origin without a preflight. Attackers bypass this by submitting GraphQL mutations as application/x-www-form-urlencoded
bash
POST /graphql
Content-Type: application/x-www-form-urlencoded
Cookie: session=victim_session_token
query=mutation%7BupdateEmail(email%3A"attacker%40evil.com")%7Bsuccess%7D%7D
Browsers send this content type freely without triggering a preflight, bypassing CORS-based CSRF defenses entirely. The correct defense rejects non-JSON content types and blocks GET-based mutations at the middleware layer before the GraphQL engine processes the request. APIsec validates both vectors automatically testing whether the server enforces POST-only for mutations, rejects non-JSON content types on state-changing operations, and requires Origin header validation for sensitive mutations. This follows the OWASP GraphQL Cheat Sheet's explicit guidance on method enforcement as a CSRF control layer.
Testing Input Validation
Test variables with malicious payloads, including SQL injection strings, XSS payloads, command injection attempts, and oversized inputs. Submit special characters, extremely long strings, and format-breaking characters. Implement continuous testing throughout development.
GraphQL Security Best Practices
Disable Introspection in Production
Configure your GraphQL server to reject introspection queries in production environments. Most GraphQL frameworks provide environment-based introspection toggles. Development and staging environments benefit from introspection, while production should disable it completely.
Implement Query Depth Limiting
Set maximum nesting levels for queries based on your API's exposure level:
Reject queries exceeding these limits before execution. Popular libraries like graphql-depth-limit integrate seamlessly with Apollo Server and Express GraphQL.
Implement Query Complexity Analysis
Calculate query cost before execution based on requested fields, nesting depth, and list sizes. Assign complexity scores to fields:
- Simple fields: 1 point
- Lists: 10 points
- Nested lists: 50+ points
Reject queries exceeding your complexity threshold (typically 1000-5000 points depending on infrastructure). Following API security best practices helps establish appropriate limits.
Enforce Field-Level Authorization
Check permissions for every field in your resolvers. Never assume query-level authorization protects nested fields. Implement middleware that verifies user permissions before returning field data. Return null for unauthorized fields or throw explicit errors. Use libraries like graphql-shield for declarative field-level authorization rules.
Implement Intelligent Rate Limiting
Apply rate limiting accounting for GraphQL patterns:
- Count operations in batched requests as separate requests
- Factor query complexity into rate limit calculations
- Apply per-user and per-IP limiting
- Implement sliding window algorithms
- Consider query cost in limit thresholds
Validate All Inputs
Validate every variable and argument. Use schema-based validation libraries that enforce string length limits (typically 255-500 characters), email and URL format validation, integer and float ranges, enum value restrictions, and required field enforcement. Libraries like graphql-constraint-directive provide declarative input validation.
Enable Query Timeout and Use Persisted Queries
Set maximum execution time (5-30 seconds for most queries). Pre-approve queries during development and reject unapproved queries in production. Persisted queries eliminate arbitrary query execution, reducing the attack surface to known, tested operations.
Automating GraphQL Security Testing
Manual testing misses subtle security flaws in complex schemas. Automated security testing provides comprehensive coverage of GraphQL-specific vulnerabilities.
APIsec tests GraphQL APIs for introspection exposure, nested query attacks, field-level authorization bypass, batch query abuse, and input validation vulnerabilities. The platform understands GraphQL schema structures and generates security tests automatically. Integration with CI/CD pipelines ensures every schema change undergoes security verification before deployment.
Start testing your GraphQL APIs to identify and fix security flaws before attackers exploit them.
Continuous GraphQL Security Testing in CI/CD with Schema Change Detection
APIsec tests GraphQL APIs across the full spectrum of GraphQL vulnerabilities, including introspection exposure, Apollo suggestion leakage, introspection bypass via alternate HTTP methods, nested query attacks, field-level authorization bypass, BOLA via argument manipulation, alias-based brute force, operation limit violations, CSRF over GET and form-encoded requests, batch query abuse, and input validation gaps. The platform understands GraphQL schema structures and generates security tests automatically from your schema definition without requiring manual test case authoring.
GraphQL schemas evolve constantly, new types, fields, mutations, and arguments are added with every sprint, and each change potentially introduces new attack surfaces. Here are the ways APIsec integrates continuous GraphQL security testing into your CI/CD pipeline:
yaml
name: GraphQL Security Testing
on:
push:
branches: [main, staging]
jobs:
graphql-security:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Run APIsec GraphQL Security Scan
uses: apisec/apisec-github-action@v1
with:
api-key: ${{ secrets.APISEC_API_KEY }}
graphql-endpoint: ${{ secrets.GRAPHQL_ENDPOINT }}
schema-path: ./schema.graphql
fail-on-severity: HIGH
- Schema change detection monitors your schema on every pipeline run and auto-generates security tests for new fields, types, and mutations the moment they appear testing new arguments for BOLA, new mutations for CSRF exposure, and new types for field-level authorization enforcement without requiring teams to manually update test suites
- Pre-deployment security gates block deployment when critical GraphQL security vulnerabilities are detected, such as introspection enabled in a production build or a new mutation accessible without authentication
- Regression testing reruns the full operation limit test suite on every build, max root fields, alias counts, query byte size, complexity thresholds, catching controls that silently break when schema libraries are upgraded
- Historical vulnerability tracking maintains a security posture history tied to schema versions, allowing teams to identify exactly which schema change introduced a vulnerability and correlate findings with deployment timelines
This positions GraphQL API security as a continuous property of the development process rather than a periodic audit event, the approach the OWASP GraphQL Cheat Sheet recommends for teams operating at modern deployment frequency. Start testing your GraphQL APIs with APIsec to identify and fix GraphQL security risks before attackers exploit them.
Key Takeaways
- GraphQL's single endpoint requires different security controls than REST's multiple endpoints
- Introspection exposure allows attackers to download complete schemas.
- Query depth and complexity limits prevent resource exhaustion attacks.s
- Field-level authorization is mandatory for every sensitive field.ld
- Batch queries bypass traditional rate limiting without GraphQL-aware controls.
FAQs
What makes GraphQL security different from REST API security?
GraphQL uses a single endpoint with flexible queries requiring field-level authorization, while REST uses multiple endpoints with fixed responses.
Should introspection be enabled in production GraphQL APIs?
No. Disable introspection in production to prevent attackers from discovering your complete schema and potential attack vectors.
How do you prevent GraphQL query depth attacks?
Implement query depth limiting (5-10 levels maximum) and complexity analysis that calculates query cost before execution.
What is field-level authorization in GraphQL?
Field-level authorization checks permissions for every field, not just the query entry point, preventing unauthorized data access.
How often should GraphQL APIs be security tested?
Run automated security testing with every schema change and conduct manual penetration testing quarterly.
.webp)
