Authorize Nested GraphQL Fields

A parent GraphQL object may be authorized while a nested field fetches data from another service under a broad credential. For example, a project can be visible to a member while its billing, audit, or attachment field needs a narrower grant. OWASP GraphQL guidance calls for access control and careful resolver behavior.

Build a field-resolver matrix

For one important type, list each sensitive child field, its data source, owner relation, required permission, and error behavior.

A parent-level check can be reused only if it truly covers the child action. Check loader caches for keys that omit tenant or role context. A resolver that returns null for an unauthorized field still needs to avoid fetching and logging the private value first.

Test mixed selections

Create synthetic A and B records and roles with different field grants. Query each child alone and in one combined selection. Test an alias and repeated nested path to confirm that authorization is not skipped by query shape. Check the response data, error details, and backend side effects. A 200 HTTP status does not mean the field was safely denied.

The OWASP Authorization Cheat Sheet supports resource and action-specific decisions. This matrix turns those decisions into field-level tests. It also helps identify whether a field should be removed from a general type and exposed through a separate authorized operation. Do not claim the whole GraphQL schema is secure from one type's test. Record covered types and pending fields by build.

Review resolver errors as data outputs. An error that names a private billing account can leak information even when the field value is null. Add a synthetic marker to the denied field and inspect both data and errors in the same test.