Assessing GraphQL API endpoints for introspection leaks, injection attacks, authorization flaws, and denial-of-service vulnerabilities during authorized security tests.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Assessing GraphQL API endpoints for introspection leaks, injection attacks, authorization flaws, and denial-of-service vulnerabilities during authorized security tests.
During authorized penetration tests when the target application uses a GraphQL API
When assessing single-page applications (React, Vue, Angular) that communicate via GraphQL
For evaluating mobile app backends that expose GraphQL endpoints
When testing microservice architectures with a GraphQL gateway or federation
During bug bounty programs targeting GraphQL-based APIs
How to CONFIRM a Hit (avoid false negatives)
Positive signal: a query/mutation actually returns sensitive data (or causes a measurable effect) under the access level being tested — confirm the data in the response body, not just a 200 or the existence of a field.
Schema knowledge alone is not impact; tie every finding to a query that demonstrably succeeds.
Do NOT conclude "not vulnerable" until you have:
Attempted introspection AND, if disabled, run schema enumeration (clairvoyance) — a field that exists but isn't introspectable can still be queried.
Tested unauth and low-priv queries/mutations for sensitive types/fields (passwordHash, ssn, admin mutations) and confirmed they return data or take effect.
Tried batching / aliasing to defeat rate limits (e.g. many login/verifyOTP aliases in one request) and confirmed more attempts processed than the HTTP-level limit allows.
Tested deep nesting / circular fragments / huge pagination and confirmed measurable resource impact (latency, errors), not just acceptance.
Checked injection (SQL/NoSQL/SSRF) in arguments and confirmed via returned data or out-of-band callback.
Distinguish an enforced error ("not authorized") from a partial/null response that still leaks data in adjacent fields.
Prerequisites
Authorization: Written penetration testing agreement for the target
Burp Suite Professional: With InQL extension for GraphQL scanning
GraphQL Voyager: Schema visualization tool
InQL Scanner: Burp extension for GraphQL introspection and query generation
Altair GraphQL Client: Desktop GraphQL client for interactive testing
clairvoyance: GraphQL schema enumeration when introspection is disabled
curl: For manual GraphQL query submission
Workflow
Step 1: Discover and Fingerprint GraphQL Endpoints
Locate GraphQL endpoints and confirm GraphQL is running.
GraphQL batching attack tool for rate limit bypass
Common Scenarios
Scenario 1: Introspection Exposes Internal Schema
Introspection is enabled in production, revealing internal types like AdminSettings, InternalUser, and mutations like deleteAllUsers. This provides a complete roadmap for further attacks.
Scenario 2: Missing Field-Level Authorization
The User type exposes passwordHash, ssn, and internalNotes fields. While the frontend only queries name and email, any authenticated user can request sensitive fields directly.
Scenario 3: Batch Login Bypass
The GraphQL endpoint accepts batch queries. By sending 1000 login mutation attempts in a single HTTP request, an attacker bypasses IP-based rate limiting that only counts HTTP requests.
Scenario 4: Nested Query DoS
A social network API allows querying friends { friends { friends { ... } } } up to unlimited depth. A 10-level nested query causes the server to process millions of database queries, resulting in denial of service.
Output Format
## GraphQL Security Assessment Report
**Target**: https://target.example.com/graphql
**Engine**: Apollo Server 4.x
**Assessment Date**: 2024-01-15
### Findings Summary
| Finding | Severity | Status |
|---------|----------|--------|
| Introspection enabled in production | Medium | VULNERABLE |
| Missing field-level authorization | High | VULNERABLE |
| No query depth limit | High | VULNERABLE |
| Batch query rate limit bypass | High | VULNERABLE |
| GraphiQL IDE exposed | Low | VULNERABLE |
| SQL injection in user query | Critical | VULNERABLE |
| CSRF on mutations | Medium | PASS (custom header required) |
### Critical: SQL Injection via user Query
**Location**: `user(name: String)` query argument
**Payload**: `{ user(name: "' OR 1=1--") { id email role } }`
**Impact**: Full database read access via GraphQL interface
### High: Batch Authentication Bypass
**Location**: POST /graphql (array body)
**Payload**: Array of 100 login mutations in single request
**Impact**: Rate limiting bypassed; 100 password attempts per HTTP request
### Recommendation
1. Disable introspection in production environments
2. Implement field-level authorization on all sensitive fields
3. Set query depth limit (max 7-10 levels)
4. Set query complexity limit and cost analysis
5. Disable or rate-limit batch queries
6. Remove GraphiQL/Playground from production
7. Parameterize all database queries in resolvers
