Proposal to Enhance GraphQL Section (4.3)

[ajayojha]

trafficstars

As discussed in GitHub Discussion #3193, I am opening this issue to formally track the proposal related to GraphQL-specific security controls. I will open additional issues for other requirements after this one is addressed to ensure clarity and focus.

I have reviewed the ASVS v5.0 document and the OWASP ASVS scope content thoroughly.

I want to clarify that I am not proposing implementation-level mechanisms or technology-specific configurations, which would be out of scope. Instead, this is a suggestion to refine and contextualize existing security requirements within the ASVS model. It does not overlap with OWASP Cheat Sheet guidance or verification methods.

Problem Statement

Section 4.3 of ASVS v5.0 currently focuses on GraphQL-specific risks such as:

4.3.1 – Query cost/depth limitation

4.3.2 – Disabling introspection in production

However, based on extensive review of real-world GraphQL vulnerabilities (especially in enterprise systems), I’d like to suggest adding or clarifying two critical security requirements:

• Insufficient input validation at the resolver level — developers often assume GraphQL schemas enforce safety, but type coercion is not strict validation, and business logic validation is frequently missed.

• Missing field-level authorization — GraphQL allows users to request deeply nested and sensitive fields. Without resolver-specific access control, users can easily overreach authorized access.

Why General Requirements Are Not Sufficient

While input validation (Chapter V2) and authorization (Chapter V8) are well-defined in ASVS, they are commonly interpreted in a RESTful context. Because GraphQL has:

• A single dynamic endpoint,
• A runtime execution model via resolvers, and
• Field-level granularity in responses,

...it becomes unclear to many developers that those same principles must be re-implemented inside each resolver.

This results in security gaps—even in applications that follow ASVS at a high level.