offensive-graphql

# 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:
    - Check for Information Disclosure (e.g., user data, configuration).
    - Test for Authorization Bypass (IDOR, insufficient permission checks).
    - Look for Injection (SQLi, NoSQLi, Command Injection) in input fields.
    - Test for Denial of Service (complex/deeply nested queries, batching abuse).
    - Explore Mutations for unintended state changes.
    - Check Subscriptions for data leakage.
    - Verify persisted/signed queries enforced in production; depth/complexity limits.
5.  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: