In a GraphQL resolver change, check that authorization runs on nodes and edges, that fields respect the caller's permissions, that direct id lookups cannot reach other users' data, that mutations are restricted, and that query limits and introspection settings are not weakened. Resolvers are where access control lives.
Why resolvers need their own checklist
A REST endpoint has one route and one place to add a check. A GraphQL schema exposes a graph, and the same object can be reached through many paths. A check on one path does not protect the others. The OWASP GraphQL Cheat Sheet makes this point directly: enforce authorization checks on both edges and nodes, and it cites a bug report where nodes lacked checks while edges had them.
Reviewer checklist
1. Authorization at every access point
The cheat sheet says to always validate that the requester is authorized to view or modify the data, which prevents IDOR issues including broken object level and broken function level authorization. Ask: in this resolver, where is the check, and does it use the caller's identity?
2. Nodes and edges
If the change adds a field that returns another object, is there a check on that object too, or does it trust that the parent was checked? A user who may see an order may not be allowed to see every customer record linked from it.
3. Direct lookups by id
The same cheat sheet warns that developers sometimes assume possession of an id means the caller should have access, and notes that schemas sometimes expose node or nodes fields that fetch objects directly by id. Check that any such lookup applies the same access rules as the normal path.
4. Field level access
Should every consumer see every field? If a new field is sensitive, such as an email address, a price tier or an internal note, look for a check that the requester may read it.
5. Mutations
For a mutation, ask who may call it and which fields they may change. The cheat sheet says setups where read access alone is intended, or certain parties alone should modify certain fields, need explicit controls.
6. Input validation
Does the schema use specific types, enums and custom scalars, with allowlist validation of values? The cheat sheet recommends defining input schemas for mutations and rejecting invalid input without revealing too much about validation.
7. Query cost
Does the change add a nested relationship, such as album to songs to album? The cheat sheet recommends depth limits, amount limits, pagination, timeouts, and in some cases cost analysis. A new self-referencing field can reopen a hole your limits closed.
8. Batching
The cheat sheet describes batching attacks, where aliases or batched requests let a caller enumerate many objects in one network call. Check that rate limiting and object authorization do not assume one object per request.
9. Configuration
Introspection and GraphiQL should be disabled in production or publicly reachable environments, according to the cheat sheet. Check that no change in the pull request, including environment files, switches them on.
A quick example of what to flag
Comment: [blocking] The new customer field on Order has no check that the caller
may view that customer. Authorize on the node, not just the parent edge.
Where tooling helps
Schema linting and tests can enforce some rules, such as depth limits being configured. They cannot judge whether a given user should see a given field. That is a business decision, which is why a human reviewer remains necessary.
Quick check
Is disabling introspection enough to protect the schema?
No. OWASP lists it as one setting among several. Access control on every resolver is still needed, because attackers can guess field names.
Do I need cost analysis?
Not always. The cheat sheet quotes advice to test your own API with a nasty query first and implement cost analysis if you need it.
Sources
Last reviewed: 19 October 2026.
