OWASP / OWASP/ASVS

Proposal to Enhance GraphQL Section (4.3)

Open
#3,197 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

2) Awaiting response V4 (prev V13)
Dominant language
HTML
Stars
3.6k
Forks
831
Avg merge
7h 55m
Merged PRs (30d)
4

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with Section 4.3 of the ASVS v5.0 document and read GitHub Discussion #3193 for the proposal context. Compare the existing controls 4.3.1 and 4.3.2 with the general requirements in Chapters V2 and V8; done means agreeing on the scope and wording of GraphQL-specific resolver validation and field-level authorization controls.

Written by the indexing model from the issue text.

Assessment

Tech stack
graphql
Domain
api, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.