Claude-Red

SKILL: GraphQL Vulnerabilities

Metadata

• Skill Name: graphql-security
• Folder: offensive-graphql
• Source: https://github.com/SnailSploit/offensive-checklist/blob/main/graphql.md

Description

GraphQL security testing checklist: introspection abuse, batching attacks, query depth/complexity DoS, field suggestion enumeration, IDOR via GraphQL, injection through arguments, authorization bypass. Use when assessing GraphQL endpoints in web app tests or bug bounty.

Trigger Phrases

Use this skill when the conversation involves any of: GraphQL, introspection, batching attack, query depth, GraphQL injection, GraphQL IDOR, field suggestion, GraphQL auth bypass, GraphQL DoS, GraphQL security

Instructions for Claude

When this skill is active:

1. Load and apply the full methodology below as your operational checklist
2. Follow steps in order unless the user specifies otherwise
3. For each technique, consider applicability to the current target/context
4. Track which checklist items have been completed
5. Suggest next steps based on findings

Full Methodology

GraphQL Vulnerabilities

Shortcut

1. Identify GraphQL Endpoint: Look for common paths like /graphql, /graphiql, /graphql.php, /graphql/console. Check network requests in browser developer tools.
2. Introspection Query: Send an introspection query to fetch the schema. Tools like GraphiQL or Postman can help. query={__schema{types{name}}}
3. Analyze Schema: Look for sensitive types, fields, mutations, and subscriptions. Pay attention to authorization logic.
4. Test Queries/Mutations:
5. Check for Information Disclosure (e.g., user data, configuration).
6. Test for Authorization Bypass (IDOR, insufficient permission checks).
7. Look for Injection (SQLi, NoSQLi, Command Injection) in input fields.
8. Test for Denial of Service (complex/deeply nested queries, batching abuse).
9. Explore Mutations for unintended state changes.
10. Check Subscriptions for data leakage.
11. Verify persisted/signed queries enforced in production; depth/complexity limits.
12. No Introspection? Try common field/type guessing (e.g., user, admin, query, mutation). Use tools like clairvoyance or inql.

Mechanisms

• Over-Fetching: Clients can request excessive data, potentially leading to DoS or information disclosure if not properly limited.
• Under-Fetching/N+1 Problem: Primarily a performance issue—poorly designed resolvers make dozens of backend calls (N+1). While not a direct data‑exposure risk, extreme latency can create timing side‑channels an attacker could measure.
• Insecure Direct Object References (IDOR): Exposing internal IDs allows attackers to potentially access unauthorized data by guessing/enumerating IDs.
• Insufficient Authorization: Missing or flawed checks on types, fields, mutations, or subscriptions.
• Input Validation Issues: Failure to sanitize or validate user input can lead to injection attacks (SQLi, NoSQLi, XSS, SSRF) if resolvers interact with backend systems insecurely.
• Introspection Enabled in Production: Exposes the entire schema, simplifying reconnaissance for attackers.
• Batching Abuse: Sending multiple queries/mutations in a single request can overwhelm the server (DoS) or bypass rate limiting.
• Lack of Depth/Complexity Limiting: Allows excessively nested or complex queries, leading to DoS.
• Directive Flooding: Sending thousands of @include/@skip directives in a single query can exhaust parser and validation phases, triggering DoS (e.g., CVE‑2024‑47614 in async‑graphql).
• Incremental Delivery: @defer/@stream can multiply work and leak partial data; must be guarded by cost and auth checks on deferred subtrees.
• File Uploads: Implementations using graphql-upload or custom multipart handling can inherit classic upload bugs (path traversal, content-type trust, temp file exposure).
• Federation/Gateway: Cross-subgraph authorization gaps, entity resolver overfetching, and inconsistent role enforcement at the router vs. subgraphs.
• CSRF Considerations: If cookie‑based auth is used, enforce header + Origin validation; prefer Authorization header.
• WebSocket Security: GraphQL subscriptions over WebSocket often lack proper authorization on long-lived connections; auth tokens in connection params may not be re-validated after expiry.
• Field Suggestions: Error messages that suggest valid field names when invalid ones are queried can leak schema information even with introspection disabled.
• Relay Global IDs: Base64-encoded Type:ID patterns (e.g., base64("User:123")) are commonly used and can be decoded to reveal internal IDs.
• Apollo/Hasura Leaks: Production Apollo Server instances may leak schema via query extensions; Hasura permissions misconfiguration can expose direct DB access.
• Header Injection: x-hasura-* headers or custom auth headers may be trusted without validation, enabling privilege escalation.

Hunt

Preparation

• Identify the GraphQL endpoint(s).
• Obtain the schema via introspection or guessing.
• Understand the application context and potential sensitive data/actions.

Techniques

• Schema Analysis: Use tools like GraphQL Voyager or manually review the schema for sensitive keywords (admin, password, config, secret), authorization directives, and complex relationships.
• Query Fuzzing: Use tools like inql or custom scripts to fuzz queries, mutations, and arguments.
• Authorization Testing:
• Try accessing data/mutations meant for higher-privileged users.
• Test IDOR by replacing IDs in queries/mutations.
• Check if different roles see different schema subsets (if applicable).
• Verify router and subgraphs enforce identical authz decisions.
• Injection Testing: Inject payloads (SQL, NoSQL, OS command, XSS, SSRF) into string arguments.
• DoS Testing:
• Deeply nested queries (query { user { friends { friends { ... } } } }).
• Large limits in list arguments (query { users(limit: 99999) { id } }).
• Query batching abuse.
• Field duplication/aliases (query { u1: user(id:1){id} u2: user(id:1){id} ... }).
• Directive flooding by attaching a very long chain of @include or @skip directives to safe fields.
• Incremental delivery pressure: attach many @defer/@stream segments to expand compute and memory footprint.
• Business Logic Flaws: Test mutations for race conditions, logical errors, or unintended side effects.
• Upload testing: multipart spec edge cases (path traversal via map, temp file exposure) and file‑type checks.
• WebSocket Subscription Testing:
• Tamper with connection_init payload (JWT in connectionParams)
• Test subscription flooding without rate limiting
• Verify auth token expiry is enforced on long-lived WS connections
• Test for cross-user subscription leaks via predictable subscription IDs
• Field Suggestion Probing: Send invalid field names and analyze error messages for schema hints ("Did you mean...?" responses)
• Relay ID Decoding: Identify base64-encoded global IDs (e.g., id: "VXNlcjoxMjM="), decode to extract type and numeric ID, test IDOR
• Apollo Extensions: Try ?extensions={"persistedQuery":{...}} or check for apollo-server-testing header in responses
• Hasura Header Injection: Test x-hasura-role, x-hasura-user-id, x-hasura-org-id headers for authorization bypass

Advanced Testing

• Reverse engineer client-side code making GraphQL requests.
• Analyze traffic between microservices if GraphQL is used internally.
• Test subscription endpoints for authorization issues and data leakage over time.

Bypass Techniques

Introspection Disabled

Use wordlists (SecLists has GraphQL lists) with tools like clairvoyance or GraphQLmap to guess types, fields, and arguments. Analyze client-side code for hints.

• Quick probe: query { __typename } often succeeds even when full introspection is disabled and confirms a GraphQL endpoint.

• Use wordlists (SecLists has GraphQL lis