GraphQL Testing
Core Posture
Treat GraphQL as a resolver graph, not a single endpoint. Every field, nested object, mutation, alias, and node lookup needs its own authorization, validation, and cost control.
Priority Patterns
- Data leaks: private emails, payment transactions, report metadata, private list members, billing docs, team fields, and nested admin data.
- Mutations: delete, copy, generate session, update role, add rules, verify phone, and account recovery operations.
- Authorization drift: REST denies while GraphQL resolver returns data; parent authorized but child field leaks.
- Token-scope mismatch: app or user token has narrower intended scope than GraphQL allows.
- DoS: mutation aliasing, deep nesting, batching, fragments, introspection-like expansion, and expensive connections.
- SSRF/injection: URL fields, preview queries, import/export mutations, filters, search, and custom scalar parsing.
Assessment Loop
- Inventory operations from traffic, bundles, persisted query names, mobile apps, and errors.
- Map object IDs, global node IDs, variables, tenant selectors, cursors, and fragments.
- Compare roles and tokens across the same query/mutation.
- Test nested fields and resolver-specific authorization, not only top-level operation access.
- Test cost and batching carefully with bounded aliases, depth, and list sizes.
- Confirm leaked data, side effects, scope breakout, or resource impact.
High-Value Cues
| Cue |
Ask |
node(id:) |
Can any global ID fetch private objects? |
| Nested field |
Is parent auth reused incorrectly for child data? |
| Mutation input |
Can role, tenant, owner, or object IDs be swapped? |
| Alias/batch |
Can one request multiply work or actions? |
| Token scope |
Does GraphQL ignore REST/API token limitations? |
| Hidden op |
Are old/admin operation names still accepted? |
Variant Playbook
- Swap IDs in variables, input objects, fragments, nested objects, and connection cursors.
- Request minimal vs expanded fields across roles.
- Try aliases, fragments, batching, old operation names, persisted query IDs, and introspection alternatives.
- Compare REST and GraphQL for the same action.
- Test deleted, archived, pending, private, cross-tenant, and removed-member objects.
- Bound DoS checks by small alias/depth increments and timing deltas.
Confirmation Discipline
Strong evidence shows unauthorized field data, unauthorized mutation side effect, token scope breakout, or measurable cost amplification. Rule out public fields and accepted-but-ignored variables.
References
Read references/advanced-methodology.md only when the task needs deeper operation inventory, resolver authorization matrix, mutation checks, batching/cost review, confirmation checklist, or remediation guidance.
1---2name: graphql3description: Advanced GraphQL security testing methodology for bug bounty and application security work. Use when testing or reviewing GraphQL queries, mutations, subscriptions, schema exposure, resolver authorization, nested data leaks, IDOR/BOLA in variables, mutation aliasing DoS, batched operations, global node IDs, token scope mismatch, hidden admin operations, SSRF through GraphQL fields, and REST/GraphQL permission drift.4---56# GraphQL Testing78## Core Posture910Treat GraphQL as a resolver graph, not a single endpoint. Every field, nested object, mutation, alias, and node lookup needs its own authorization, validation, and cost control.1112## Priority Patterns1314- Data leaks: private emails, payment transactions, report metadata, private list members, billing docs, team fields, and nested admin data.15- Mutations: delete, copy, generate session, update role, add rules, verify phone, and account recovery operations.16- Authorization drift: REST denies while GraphQL resolver returns data; parent authorized but child field leaks.17- Token-scope mismatch: app or user token has narrower intended scope than GraphQL allows.18- DoS: mutation aliasing, deep nesting, batching, fragments, introspection-like expansion, and expensive connections.19- SSRF/injection: URL fields, preview queries, import/export mutations, filters, search, and custom scalar parsing.2021## Assessment Loop22231. Inventory operations from traffic, bundles, persisted query names, mobile apps, and errors.242. Map object IDs, global node IDs, variables, tenant selectors, cursors, and fragments.253. Compare roles and tokens across the same query/mutation.264. Test nested fields and resolver-specific authorization, not only top-level operation access.275. Test cost and batching carefully with bounded aliases, depth, and list sizes.286. Confirm leaked data, side effects, scope breakout, or resource impact.2930## High-Value Cues3132| Cue | Ask |33| --- | --- |34| `node(id:)` | Can any global ID fetch private objects? |35| Nested field | Is parent auth reused incorrectly for child data? |36| Mutation input | Can role, tenant, owner, or object IDs be swapped? |37| Alias/batch | Can one request multiply work or actions? |38| Token scope | Does GraphQL ignore REST/API token limitations? |39| Hidden op | Are old/admin operation names still accepted? |4041## Variant Playbook4243- Swap IDs in variables, input objects, fragments, nested objects, and connection cursors.44- Request minimal vs expanded fields across roles.45- Try aliases, fragments, batching, old operation names, persisted query IDs, and introspection alternatives.46- Compare REST and GraphQL for the same action.47- Test deleted, archived, pending, private, cross-tenant, and removed-member objects.48- Bound DoS checks by small alias/depth increments and timing deltas.4950## Confirmation Discipline5152Strong evidence shows unauthorized field data, unauthorized mutation side effect, token scope breakout, or measurable cost amplification. Rule out public fields and accepted-but-ignored variables.5354## References5556Read `references/advanced-methodology.md` only when the task needs deeper operation inventory, resolver authorization matrix, mutation checks, batching/cost review, confirmation checklist, or remediation guidance.
yafet-dev