GraphQL APIs
Treat each GraphQL operation, resolver, and returned field as a separate server-side authorization and disclosure decision.
This is the complete downloadable file. Open plain text ↗
---
name: graphql
description: "Treat each GraphQL operation, resolver, and returned field as a separate server-side authorization and disclosure decision."
---
# GraphQL APIs
Treat each GraphQL operation, resolver, and returned field as a separate server-side authorization and disclosure decision.
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
## Bring to the review
- Schema and operation definitions
- Resolver or service authorization design
- Approved role contexts
## Review guide
### 1. Classify operations
Group queries, mutations, subscriptions, batch operations, and persisted operations by the resources they read or change.
### 2. Trace resolver authority
Verify each resolver forwards caller and tenant context to the service that owns the protected object.
### 3. Review field disclosure
Check nested objects, fragments, errors, and connection edges for fields beyond the caller's policy.
### 4. Contain exceptions
Ensure authorization failures stop execution and do not produce partial protected data.
## What to produce
- Operation-to-resource map
- Resolver authorization trace
- Field disclosure review
## Common mistakes
- Assuming schema visibility grants access
- Skipping nested resolver checks
- Treating an error as harmless without reviewing its data
## Reading and source context
### Resources
- [GraphQL-Ruby: authorization exceptions must stop execution](https://vulns.co/research/resources/graphql-ruby-2026-authorization-exception-integrity/)
- [Microsoft Graph batching: preserve each member authorization outcome](https://vulns.co/research/resources/microsoft-graph-batch-member-authorization-outcomes/)
- [Google AIP-158: pagination continuation does not grant resource authority](https://vulns.co/research/resources/google-aip-158-pagination-authorization-boundary/)
### Diagrams
- [Combined views preserve every source's access boundary](https://vulns.co/research/diagrams/combined-view-source-authorization/)
### Reports
- [GitHub comparison output lacked source-repository authorization](https://vulns.co/research/reports/github-cross-repository-comparison-authorization-2025/)
## Provenance
Editorial guide by vulns.co / GK Data. Updated 2026-10-11.
Library snapshot: 2026-10-04; commit d5550c7891119cf1379e235721541c947850a3b3.
The guide is an editorial synthesis. Linked records preserve their own sources and review dates.
Reader: https://vulns.co/skills/graphql/
The review
What to look for
Defensive study and review of artifacts supplied by their owner. Record missing evidence as an open question.
Classify operations
Group queries, mutations, subscriptions, batch operations, and persisted operations by the resources they read or change.
Trace resolver authority
Verify each resolver forwards caller and tenant context to the service that owns the protected object.
Review field disclosure
Check nested objects, fragments, errors, and connection edges for fields beyond the caller's policy.
Contain exceptions
Ensure authorization failures stop execution and do not produce partial protected data.
What to produce
- Operation-to-resource map
- Resolver authorization trace
- Field disclosure review
Common mistakes
- Assuming schema visibility grants access
- Skipping nested resolver checks
- Treating an error as harmless without reviewing its data
Continue the study
Reading & source context
Editorial notes above connect these references. Open each record for its original source and review date.
Visual models
Connected disclosures
From the field toolkit
Guide by GK Data · Research snapshot 2026-10-04.
Sources and review dates are preserved in the library provenance.