Authorize GraphQL Node Lookups

A GraphQL node field can offer a second path to the same record that a normal query protects. A globally unique ID is a locator, not proof that the caller may read the object. The OWASP GraphQL Cheat Sheet calls for access control on the resolver paths that return data.

Trace the node resolver

Choose one tenant-owned type. Record how its node ID is decoded, which loader fetches the row, where tenant ownership is checked, and which fields can then resolve. Include batch loaders, because a cached object may serve several requests.

An authorization check only in a top-level projects query does not protect node(id). Put the rule in a shared policy or in every access path that can resolve the object. If a node is public, document its separate public-read policy; that does not make its private child fields public.

Use a controlled fixture

Create A and B synthetic records. Resolve A's node as an A member, a B member, and a former A member. Check the full response, including errors and nested fields. Then test the same ID after a role change and through a batched query. Do not stop at the HTTP status: GraphQL may return a 200 response with per-field errors.

The OWASP API Security Top 10 identifies object-level authorization risk. This resolver trace identifies the alternate lookup that can evade an otherwise correct route. Record the schema and build tested. If the owner rule differs between node and ordinary query, reconcile it before release. Conduct tests only on owned or explicitly authorized systems.