Assessing GraphQL API endpoints for introspection leaks, injection attacks, authorization flaws, and denial-of-service vulnerabilities during authorized security tests.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
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
