GraphQL Query Reviewer

Parsing is not schema validation

The GraphQL parser reads executable-document syntax. This reviewer accepts up to 30 operations and 100 uniquely named fragments. Multiple operations must be named. Duplicate names, missing fragments and circular references are rejected, including problems in unused fragments. No schema is supplied, so field existence and argument types are not checked.

How depth and breadth are counted

A field adds one depth level. Named and inline fragments do not themselves add a field level. Repeated fragment spreads contribute repeatedly to each operation count. Alias counts include expanded occurrences, and __schema or __type fields receive an introspection note. Directives and possible branches are included conservatively rather than evaluated with runtime variables.

Budgets protect the local review

Input is limited to 100,000 characters and 12,000 parser tokens. Additional limits bound AST traversal, cumulative expanded selections and nesting. Expansion stops beyond 20,000 selections or 64 field/fragment-chain levels. More than ten field levels or twenty expanded aliases produces a review observation, not an exploit verdict.

Resolver cost needs application context

Depth alone cannot describe database work, list sizes or resolver latency. No request is sent, and no operation is executed. Apply schema-aware cost controls and authorised tests in the server environment. Exported results contain structural counts rather than the supplied query text or argument values.

References

• GraphQL JavaScript language parser documentation
• GraphQL v17.0.2 parser source
• OWASP GraphQL guidance

Documentation reviewed: 1 November 2026. Rule results describe the supplied text, not a live application test.

Useful next steps

• API Access Matrix Planner
• JavaScript Syntax Pattern Checker
• Practical guides and coding projects

Maintained by MetaCyberGuru. A review point may need source, runtime or deployment context before you act on it.