GraphQL API Vulnerabilities and Common Attacks: A Technical Guide

A single GraphQL __schema query can return your entire type system: every field, every argument, every input-object shape, every admin-only mutation, every directive, and the description text your developers wrote inline. The Open Web Application Security Project (OWASP) API Security Top 10 (2023) does not list "introspection" by name, but the schema-disclosure window is the foundation for almost every later GraphQL attack documented on the National Vulnerability Database since 2022. SuiteCRM CVE-2023-47643 shipped introspection on by default in every version before 8.4.2, exposing the SuiteCRM schema and sensitive fields to unauthenticated clients on the public internet. The fix was a single configuration default. The visibility had been there for years.

That single defaulted-on flag illustrates the GraphQL security pattern. The protocol is well-designed, the canonical libraries are mature, and the top-of-funnel telemetry is reassuring: the Wallarm Annual 2025 API ThreatStats Report found 70% of organizations now use GraphQL, the Postman 2025 State of the API Report put GraphQL adoption at 33% as a cross-cutting protocol behind webhooks (50%) and WebSockets (35%), and Akamai's State of the Internet 2024 documented approximately 150 billion API attacks from January 2023 through December 2024 across all protocols. But four enduring vulnerability classes consistently surface in GraphQL pentests: introspection enabled in production, object-level and function-level authorization breakage, batching and depth attacks, and mass assignment through mutation inputs. Each maps to an OWASP API Security Top 10 (2023) category, and each is anchored on a verified CVE or a public bug bounty payout.

This post is the Stingrai team's technical explainer of the most common GraphQL API vulnerabilities and how attackers exploit them. The audience is security engineers, AppSec leads, and developers building GraphQL APIs. Every numeric claim links to its primary publisher (NVD, the GitHub Security Advisory database, OWASP, Wallarm, Akamai, Postman, Escape, PortSwigger Web Security Academy, HackerOne, or vendor security pages from Apollo, Hasura, and ChilliCream). The post does not invent CVE numbers, fabricate code, or paraphrase research without attribution.

TL;DR: ten enduring GraphQL vulnerability classes

• Introspection enabled in production. Schema disclosure via __schema and __type queries; SuiteCRM CVE-2023-47643 is the canonical example.

• Broken Object-Level Authorization (BOLA / IDOR). Querying records by id without ownership checks. OWASP API1:2023. Shopify HackerOne #2207248 paid US$5,000 for an IDOR on the GraphQL BillingDocumentDownload and BillDetails queries.

• Broken Function-Level Authorization (BFLA). Admin-only mutations exposed to non-admin tokens. OWASP API5:2023. Hasura GraphQL Engine CVE-2022-46792 mishandled row-level authorization in the Update Many API for Postgres backends.

• Mass assignment / BOPLA. Mutations accepting input fields the client should not set. OWASP API3:2023.

• Batching and alias abuse. One HTTP request, N resolver invocations. Directus CVE-2024-39895 (CVSS 6.5) let an authenticated user multiply database load linearly with the alias count.

• Query depth and complexity DoS. graphql-java CVE-2023-28867, graphql-js CVE-2023-26144, gqlparser CVE-2023-49559, async-graphql CVE-2024-47614, Hot Chocolate CVE-2026-40324, and Apollo Router CVE-2025-32032 all live in this class.

• Field-suggestion information disclosure. Clairvoyance reconstructs schemas from "Did you mean...?" errors even with introspection disabled.

• CSRF on GraphQL endpoints. Apollo Server 2's bundled graphql-upload library was vulnerable via multipart/form-data (GHSA-2p3c-p3qw-69r4). Apollo Server 4 defaults csrfPrevention to true.

• GraphQL injection. SQLi, NoSQLi, and command injection through resolvers; same root cause as REST injection but obscured by the GraphQL abstraction.

• Persisted-query allowlist bypass and parser DoS. Apollo Router CVE-2025-32032 demonstrated that recursive fragments could exhaust thread pools during query planning, bypassing per-operation guardrails.

Figure 1: The ten enduring GraphQL vulnerability classes and their OWASP API Security Top 10 (2023) categories. Each row is anchored on a verified CVE or a public bug bounty disclosure. Sources: OWASP API Security Top 10 (2023), NVD, GitHub Security Advisory database, HackerOne Hacktivity.

Why GraphQL changes the attack surface

GraphQL is a query language and an execution engine published by Meta in 2015 and now governed by the GraphQL Foundation. The protocol introduces five design properties that matter for security:

1. A single endpoint. Most GraphQL servers expose /graphql as the only HTTP endpoint, and every operation flows through it. This reduces inventory drift (a partial win against OWASP API9:2023 Improper Inventory Management) but obscures per-operation visibility for traditional WAFs and rate limiters that bucket by URL.

2. A typed schema. The schema declares every type, field, argument, mutation, and directive. The strong type system catches some classes of bug at schema time but lets clients query and mutate any data the schema exposes.

3. Introspection. The protocol includes a built-in __schema query that returns the full type system as data. Introspection is invaluable in development and toxic in production.

4. Aliases and fragments. A client can rename and reuse fields freely within a query, and fragments allow spreading a selection set across many queries. These are quality-of-life features for clients and primitive batching mechanisms for attackers.

5. Subscriptions and persisted queries. Long-lived WebSocket subscriptions and pre-registered persisted queries each have their own security considerations: long-lived auth on subscriptions, allowlist drift on persisted queries.

Together those properties create an attack surface that overlaps with REST in five categories (BOLA, BFLA, mass assignment, injection, CSRF) and adds three categories that REST does not natively expose at scale (introspection-driven schema disclosure, depth/complexity DoS, alias/batching abuse). The Wallarm 2025 ThreatStats report observed that "no GraphQL-specific breaches" were reported in Q2 2025, then noted that this likely reflects detection gaps rather than safety because GraphQL's single dynamic endpoint obscures visibility for traditional security controls. That ambiguity is exactly why a working mental model matters more than a vendor dashboard.

Method 1: introspection enabled in production

Introspection is the GraphQL protocol's self-documentation feature. The two reserved meta-fields, __schema and __type, return the entire type system as data: every type and field name, every argument and its type, every input-object shape, every mutation including admin-only mutations, every directive declared on the schema, and the human-readable description text developers write inline.

For a developer, that output drives GraphiQL, Apollo Sandbox, GraphQL Voyager, and most modern IDE integrations. For an attacker, it produces an attack graph in seconds. PortSwigger's Web Security Academy GraphQL section describes the standard reconnaissance flow: dump the schema, render it with Voyager, and trace paths from public roots to sensitive types.

The CVE that anchors this class is SuiteCRM CVE-2023-47643, an open-source customer relationship management platform that shipped its GraphQL endpoint with introspection enabled by default in every version before 8.4.2. The advisory notes that "GraphQL Introspection is enabled without authentication, exposing the scheme defining all object types, arguments, and functions" and explicitly cites sensitive fields including UserHash as schema-discoverable. The fix was the same single config change every operator should ship in production: disable introspection, keep it for development environments, and gate any developer-facing schema-explorer behind authentication.

Disabling introspection is necessary but not sufficient. GraphQL servers also implement a default field-suggestion behaviour: when a client sends a query with a misspelled or non-existent field, the server returns a "Did you mean password?" style error. Clairvoyance is the canonical tool that brute-forces a wordlist of plausible field names against the API and reconstructs the schema from those error messages. The reconstruction is partial but practical: most field-name guesses are common enough that an attacker recovers the high-value parts of the schema even when introspection is disabled. The defense is to disable both introspection and field suggestions in production. Apollo Server's request-pipeline plugins accept a configuration that strips suggestions; Hot Chocolate exposes a security overview covering the same setting.

Figure 2: A single __schema query returns the full type system. The right column maps each disclosure to the attacker's next move. Sources: PortSwigger Web Security Academy GraphQL section, OWASP GraphQL Cheat Sheet, Doyensec InQL, and Escape's State of GraphQL Security 2024.

Method 2: Broken Object-Level Authorization (BOLA / IDOR)

Broken Object-Level Authorization, ranked first in the OWASP API Security Top 10 (2023), is the single most common API vulnerability class on bug bounty boards. The pattern is simple: an API endpoint accepts an object identifier, the user is authenticated, but the server fails to verify that the user owns the object before returning it.

In REST that pattern looks like GET /api/orders/12345. In GraphQL the same vulnerability looks like:

query GetOrder { order(id: "12345") { total customer { email phone address } paymentMethod { last4 brand } } }

The fix is identical to the REST case: enforce object-level authorization in the resolver, not in the calling layer. The GraphQL twist is that introspection-discovered ID fields make the BOLA-probing surface larger. An attacker who has dumped the schema enumerates every type with an id argument and probes each in turn.

The cleanest public anchor is Shopify HackerOne report #2207248, an IDOR on the GraphQL BillingDocumentDownload and BillDetails queries that paid US$5,000 in May 2024. The report's summary describes how staff with limited permissions on one shop could query billing documents from other shops by manipulating the BillingInvoice ID. Shopify's bug bounty program, run on HackerOne, is one of the highest-volume sources of public GraphQL disclosures; the reddelexc/hackerone-reports curated list tracks several other Shopify GraphQL findings, including unauthorized access to Shopify Payments balance information and access by "No Access" permission users to GraphQL LiveView operations.

A second Shopify disclosure relevant here is HackerOne #2886723, which documented GraphQL introspection enabled on a Shopify storefront endpoint, allowing complete schema retrieval. That report ties Method 1 (introspection) and Method 2 (BOLA) together: schema disclosure made the subsequent BOLA probing far more efficient.

Method 3: Broken Function-Level Authorization (BFLA)

Broken Function-Level Authorization, OWASP API5:2023, means an API exposes admin-only or privileged functions without enforcing the authorization check on the function level. In a REST API that often manifests as /api/admin/... routes that respond to non-admin tokens. In GraphQL the same flaw appears as admin-only mutations exposed in the schema and accessible to any authenticated user.

The cleanest CVE-grade example is Hasura GraphQL Engine CVE-2022-46792, which mishandled row-level authorization in the Update Many API introduced in v2.10.0. The advisory (GHSA-g7mj-g7f4-hgrg) describes the impact: "A user could perform an update on any column they had update permissions to on any row within the target table, and subsequently retrieve any columns they had select permissions on from any impacted rows." The patches landed in 2.10.2, 2.11.3, 2.12.1, 2.13.2, 2.14.1, and 2.15.2; versions before 2.10.0 were unaffected. The vulnerability was rated critical because Hasura is widely deployed in front of Postgres backends as the GraphQL layer in multi-tenant SaaS.

Hasura's case study is instructive because the bug was not a missing authorization check; it was a corner case in how the new Update Many API combined update and select permissions. Authorization breakage at the function level often shows up that way: not as a totally absent check but as an inconsistency between checks across feature surfaces. GraphQL's schema-driven design helps detect these inconsistencies. Tools like Doyensec's InQL and GQLSpection generate every plausible mutation invocation from the schema, and a thorough pentest exercises each against several token classes (anonymous, authenticated user, admin, cross-tenant user) to find the boundary where authorization fails.

A second BFLA pattern in the wild is "admin mutation reachable through public root." Many GraphQL schemas expose a single Mutation root type, and any client that authenticates can invoke any mutation declared there. If deleteOrganization, impersonateUser, or exportTenantData is declared on the public mutation root without an explicit per-mutation authorization check, the schema-driven discovery (Method 1) plus weak authorization plumbing (Method 3) produces the breach. The OWASP GraphQL Cheat Sheet and NCC Group's GraphQL research both flag this pattern.

Method 4: Mass assignment / Broken Object Property-Level Authorization (BOPLA)

Mass assignment, captured under OWASP API3:2023 Broken Object Property-Level Authorization, happens when a mutation accepts input fields that the client should not be allowed to set. The classic case is an updateUser(input: UpdateUserInput!) mutation whose UpdateUserInput type contains a role or isAdmin boolean. Any authenticated user can pass role: "admin" or isAdmin: true because the schema exposes the field, the resolver accepts the input shape, and no allowlist is applied between the input object and the database update.

GraphQL makes this class easier to exploit, not harder. Introspection (Method 1) reveals every input-object shape: UpdateUserInput { name, email, role, isAdmin, balance, ... }. The attacker reads off the privileged fields, sends them in a mutation, and observes whether the server accepts them.

The OWASP Cheat Sheet's recommended defenses are direct: enforce input-shape allowlists per role at the resolver layer; do not deserialize input objects directly into ORM model updates; and treat any mutation that touches authorization-relevant fields (role, organization, billing, account state) as an admin-only mutation that requires a server-side ownership and privilege check before applying. Trail of Bits' Apollo Server hardening guide describes Semgrep rules that flag direct mass-assignment patterns at code review time.

Method 5: batching and alias abuse

GraphQL allows a single HTTP request to contain many operations (operation batching) and a single query to repeat the same field with different aliases (alias batching). Both behaviors are quality-of-life features for clients. Both behaviors are primitive rate-limit-bypass mechanisms for attackers.

The canonical example is credential brute-forcing. A login mutation called once per HTTP request triggers a per-IP rate limit. The same login mutation called 100 times in one HTTP request, each time with a different alias and password, fits comfortably under the per-request rate limit while attempting 100 password guesses. The same pattern works against 2FA / OTP code endpoints, password-reset codes, coupon codes, gift-card numbers, and any other low-entropy guessable token.

mutation BatchLogin { attempt1: login(email: "victim@example.com", password: "p1") { token } attempt2: login(email: "victim@example.com", password: "p2") { token } attempt3: login(email: "victim@example.com", password: "p3") { token } ... attempt100: login(email: "victim@example.com", password: "p100") { token } }

BatchQL by Assetnote and graphql-cop by Dolev Farhi automate batching and alias attacks for offensive testing. Both should be in any GraphQL pentest toolkit.

The CVE that anchors this class is Directus CVE-2024-39895 (CVSS 6.5 medium), disclosed in July 2024 against Directus, a real-time API and dashboard for SQL backends. The advisory describes the flaw: Directus's /graphql and /graphql/system endpoints failed to deduplicate resolver invocations within a single request, so an authenticated attacker could repeat an expensive relational query many times in a single request through aliases. "This forced the server to execute a large number of independent complex database queries concurrently, multiplying the database load linearly with the number of aliases. Any authenticated user, even those with minimal read-only permissions, could trigger this condition." The fix landed in 10.12.0.

Directus's bug is a common pattern: each resolver dispatches a database query without batching or de-duplication. The defense involves three controls. First, server-side limits on alias count and operation count per request (Apollo Router's request-limits documentation describes the relevant config). Second, DataLoader-style batching at the resolver layer so repeated reads collapse into one database query. Third, rate-limiting at the operation-name granularity rather than only at the HTTP-request granularity, so a 100-aliased login mutation counts as 100 login attempts rather than one HTTP request.

Method 6: query depth, complexity, and parser DoS

GraphQL schemas often allow recursive type relationships. A User has posts, each Post has an author of type User, and each User has posts again. Without a depth limit, a query can traverse this cycle indefinitely. With each level expanding fanout, the execution plan grows exponentially and the resolver layer collapses.

query DepthBomb { user(id: "1") { posts { author { posts { author { posts { # ... continue 50 levels deep } } } } } } }

The CVEs in this class are numerous and span every major GraphQL implementation. The verified set includes:

• graphql-java CVE-2023-28867. Disclosed March 2023. graphql-java did not implement adequate controls to limit recursion depth when processing nested query structures. An unauthenticated attacker could send a GraphQL document with deeply nested fields or fragments, causing the JVM to exhaust its stack space and crash the service. The advisory explicitly notes that "Attackers can leverage nested fragments, deeply nested field selections, or recursive query structures to trigger the stack consumption."

• graphql-js CVE-2023-26144. Disclosed September 2023. The npm graphql package versions 16.3.0 through 16.8.0 contained a flaw in OverlappingFieldsCanBeMergedRule.ts that lacked sufficient guards on large queries; the package failed to efficiently handle overlapping fields, leading to uncontrolled resource consumption. The GitHub Security Advisory GHSA-9pv7-vfvm-6vr7 and Red Hat's CVE record note the impact as performance degradation rather than crash, but for a high-traffic API the difference is operational.

• gqlparser CVE-2023-49559. Disclosed December 2023, CVSS 5.3 medium. The Go-based vektah/gqlparser library (used by gqlgen, the most popular Go GraphQL server) lacked a mechanism to limit the number of directives in a query. A specially crafted query with thousands of non-existent directives exhausted parser resources and produced a denial of service. A temporary patch in 2.5.13 limited request tokens to 15,000; the permanent fix in 2.5.15 made the directive limit configurable. Users of gqlgen should upgrade to v0.17.49 or later.

• async-graphql CVE-2024-47614. Disclosed September 2024. The Rust async-graphql crate had a directive-overload DoS analogous to gqlparser. The advisory references the GHSA-5gc2-7c65-8fq8 record.

• Hot Chocolate CVE-2026-40324. Disclosed in early 2026. ChilliCream's Hot Chocolate (the dominant .NET GraphQL server) shipped Utf8GraphQLParser as a recursive-descent parser without a recursion-depth limit. A crafted GraphQL document with deeply nested selection sets, object values, list values, or list types triggered a StackOverflowException at payloads as small as 40 KB. Because StackOverflowException is uncatchable in .NET, the entire worker process terminated immediately. The crash happened before validation rules ran; MaxExecutionDepth, complexity analyzers, persisted-query allowlists, and custom IDocumentValidatorRule implementations all could not intercept it. Affected versions: all before 12.22.7, 13.0.0 through 13.9.15, 14.0.0 through 14.3.0, and 15.0.0 through 15.1.13.

• Apollo Router CVE-2025-32032. Disclosed April 2025. Apollo Router versions before 1.61.2 and 2.1.1 were vulnerable to complete denial of service through thread-pool exhaustion. Recursive GraphQL fragments expanded indefinitely during query planning, and the lack of recursion or selection-growth limits allowed malicious queries to spiral. This is the federated-GraphQL equivalent of the Hot Chocolate parser DoS.

• GitLab CVE-2025-3922. Disclosed April 2025. CWE-770 (Allocation of Resources Without Limits or Throttling). The GitLab GraphQL API implementation lacked adequate safeguards to prevent resource exhaustion. Authenticated GitLab users could craft GraphQL queries that consumed excessive CPU, memory, or database connections. Affected versions ranged from 12.4 through 18.9.5, 18.10 through 18.10.3, and 18.11 through 18.11.0; patches landed in 18.9.6, 18.10.4, and 18.11.1. The advisory specifically calls out "deeply nested queries that cause exponential processing overhead and batch queries requesting large numbers of objects simultaneously" as the documented attack patterns.

The Escape "State of GraphQL Security 2024" study scanned 160 public GraphQL endpoints and 3,835 operations, found 13,720 issues including 4,527 critical-severity issues, and reported that 69% of services were susceptible to denial-of-service attacks via unrestricted resource consumption. That percentage is roughly consistent with the volume of CVEs above and with the core finding that depth and complexity controls are not enabled by default in any major GraphQL framework.

Defenses in this class are layered. Parser-level limits cap recursion depth, token count, alias count, and directive count before validation runs (Apollo Router's request-limits docs are the canonical reference). Validator-level limits implement query-cost analysis: each field has a static or dynamic cost, and the total query cost is capped per request. The GraphQL Armor middleware family implements both for Apollo and Yoga; graphql-shield layers permissions on top. None of these are a substitute for proper resolver design and DataLoader batching, but together they raise the cost of a depth-bomb attack to the point where the operator detects it before service capacity collapses.

Figure 3: Eleven verified GraphQL CVEs and security advisories from May 2022 through April 2025. Color groups: red = critical or production-impact CSRF / multi-tenant DoS; orange = parser or recursion DoS; teal = aliasing / batching DoS; navy = authorization; blue = introspection / schema disclosure; purple = XSS via SSR. Sources: nvd.nist.gov, github.com/advisories.

Method 7: field-suggestion and verbose-error information disclosure

Field suggestions are not a vulnerability per se. They are a developer-experience feature: when a query references a non-existent field, the server returns "Did you mean password?" so the developer can fix the query. In production, suggestions become a primitive schema-discovery tool. Clairvoyance is the canonical attacker tool that brute-forces a wordlist of plausible field names against the API and reconstructs the schema from the suggestions returned in errors. The reconstruction is partial but practical, because most field names are common English words or developer idioms that a wordlist of 10,000 entries comfortably covers.

Disabling introspection in production without disabling field suggestions leaves the schema discoverable through Clairvoyance. The defense is to suppress suggestions in production. Apollo Server exposes a configuration; Hot Chocolate's v15 security overview documents the equivalent for .NET; graphql-go and gqlgen require a custom error formatter that strips the didYouMean field. The OWASP GraphQL Cheat Sheet calls out this control explicitly.

Verbose-error disclosure is the related class. GraphQL servers default to returning detailed error messages, including stack traces in development mode. Production servers should sanitize errors before returning them: keep operation-name and a short error code, drop stack traces, drop file paths, drop SQL fragments. Trail of Bits and Apollo's own security overview both describe the configuration changes required.

Method 8: CSRF on GraphQL endpoints

Cross-Site Request Forgery against a GraphQL API requires three conditions: the server accepts state-changing requests via simple content types (text/plain, application/x-www-form-urlencoded, multipart/form-data) which browsers do not preflight; the server relies on cookies for authentication; and the attacker can lure a victim to a page that submits a form to the GraphQL endpoint. GraphQL servers that accept GET-encoded queries or that accept multipart/form-data POSTs without an explicit CSRF check are at risk.

The CVE that anchors this class is Apollo Server 2 graphql-upload CSRF (GHSA-2p3c-p3qw-69r4), published in May 2022 and affecting Apollo Server versions 2.0.0 through 2.25.3. The advisory describes the vulnerability: "The graphql-upload npm package can execute GraphQL operations contained in content-type: multipart/form-data POST requests. Because they are POST requests, they can contain GraphQL mutations. Because they use content-type: multipart/form-data, they can be 'simple requests' which are not preflighted by browsers." When combined with SameSite=None cookies, the attacker site could trigger arbitrary mutations on the GraphQL endpoint as the victim. The patches: Apollo Server 2 users not using uploads upgraded to 2.25.4, which automatically disables graphql-upload; users actively using uploads upgraded to Apollo Server v3.7 with CSRF prevention enabled.

Apollo Server 4 and the Apollo Router default csrfPrevention to true. The mechanism: any state-changing request must include either a non-empty X-Apollo-Operation-Name header or a non-empty Apollo-Require-Preflight header. Browsers cannot set custom headers from a cross-origin form submission without triggering a CORS preflight, so the requirement effectively prevents simple-request CSRF.

A second public anchor is the GitLab HackerOne #1122408 disclosure, "CSRF on /api/graphql allows..." which documented a related preflight-bypass against GitLab's GraphQL endpoint. The lesson: every GraphQL deployment should explicitly enforce a preflight or CSRF token, regardless of which framework it uses.

Apollo Next.js / experimental-apollo-client-nextjs CVE-2024-23841 is a related but distinct class: cross-site scripting via unsafe JSON injection during Server-Side Rendering. Apollo's Next.js client did not safely escape JSON before embedding it into the rendered HTML, so a malicious GraphQL response or user input could inject arbitrary JavaScript. The fix wrapped SuperJSON.stringify with htmlEscapeJsonString before injection. The advisory does not affect Apollo Server itself but does affect the SSR client integration that many Next.js teams use.

Method 9: GraphQL injection through resolvers

Injection vulnerabilities in GraphQL APIs are not GraphQL-specific. The injection happens at the resolver, where user-controlled values flow into the underlying datastore (SQL, NoSQL, command shell, file system) without proper parameterization. The GraphQL layer can hide the flaw because the abstraction obscures the SQL or NoSQL query that the resolver actually issues.

Two patterns recur in real engagements:

1. String-concatenation in a SQL resolver. A resolver receives a search argument and constructs a SQL query like SELECT * FROM products WHERE name LIKE '%${args.search}%'. The classic SQL injection follows. The defense is the same as in REST: use parameterized queries (SELECT * FROM products WHERE name LIKE $1), not string concatenation.

2. Input-object passthrough to a NoSQL filter. A resolver receives a filter argument whose schema is JSON (a permissive scalar) and passes it as-is to a MongoDB or Elasticsearch query. The attacker injects operators like {"$ne": null} to bypass authorization or exfiltrate data. The defense is to type the filter argument with a strict input shape and allowlist operators rather than passing arbitrary JSON.

The OWASP API Security Top 10 covers injection under API8:2023 Security Misconfiguration and API10:2023 Unsafe Consumption of APIs. The OWASP GraphQL Cheat Sheet and Doyensec's GraphQL research blog document specific resolver-level patterns to avoid. PortSwigger's Web Security Academy GraphQL labs include exercises that demonstrate the underlying SQL injection through a GraphQL query.

Method 10: persisted-query allowlists, subscriptions, and parser bypasses

Persisted queries are an Apollo-popularized optimization where the client registers a query with the server in advance, then issues operations by hash rather than by sending the full query each time. The mechanism cuts bandwidth and adds an effective allowlist: only registered queries can be executed.

The class of bug at this layer involves three patterns. First, the allowlist is configured as advisory rather than enforced; the server falls back to executing arbitrary queries when an unrecognized hash is sent. Second, the allowlist enforcement happens after the parser runs, so a parser-level DoS bypasses the allowlist entirely. Apollo Router CVE-2025-32032 illustrates this: recursive fragments expanded during query planning, exhausting threads before the persisted-query check could matter. Third, persisted-query registration endpoints are themselves authentication boundaries that need their own controls.

GraphQL subscriptions add a similar concern. Subscriptions are typically delivered over WebSocket connections that authenticate at handshake time and then stay open. Authorization checks that run only at handshake time can let a user receive subscription events even after their privileges are revoked or their session expires. The OWASP GraphQL Cheat Sheet recommends re-checking authorization at message dispatch time for any subscription that emits sensitive data.

Figure 4: Approximate share of scanned endpoints affected by each vulnerability class. Bars are not mutually exclusive: many endpoints exhibit multiple classes. Sources: State of GraphQL Security 2024 (Escape, 160 endpoints / 13,720 findings / 4,527 critical), Wallarm 2025 API ThreatStats, Akamai State of the Internet 2024.

Verified GraphQL CVEs and advisories, 2022 to 2025

The table below collects the verified CVEs and security advisories cited in this article. Every row links to a primary source. Twelve entries; eight verified at NVD or the GitHub Security Advisory database.

How to test a GraphQL API for vulnerabilities

A defensible GraphQL pentest follows a repeatable methodology. The OWASP Web Security Testing Guide provides the high-level structure; the OWASP GraphQL Cheat Sheet, the PortSwigger Web Security Academy GraphQL labs, and NCC Group's research blog provide the GraphQL-specific test cases. The following is the practical sequence Stingrai uses on a typical engagement.

1. Discovery. Find the GraphQL endpoint. The defaults are /graphql, /api/graphql, /v1/graphql, /query. PortSwigger's Burp adds a GraphQL endpoint scanner, and many sites embed Apollo Sandbox or GraphiQL on a non-default path that link headers reveal.

2. Introspection probe. Send query { __schema { types { name } } }. If the server responds with the schema, dump the full SDL. Render it with GraphQL Voyager or Doyensec's InQL.

3. Schema reconstruction (when introspection is disabled). Run Clairvoyance to reconstruct the schema from field-suggestion errors. Most schemas are 60-80% recoverable this way.

4. Authorization probing. From the recovered schema, enumerate every type with an id argument and probe BOLA by querying foreign IDs. Enumerate every mutation and probe BFLA by invoking with a low-privilege token. Enumerate every input-object shape and probe BOPLA by passing privileged-looking fields (role, isAdmin, tenantId, balance).

5. Batching and alias. Use BatchQL and graphql-cop to test alias-batched login, password-reset, and OTP brute-force surfaces. Confirm whether per-operation rate limits exist or only per-request.

6. Depth and complexity. Use GraphCrawler and graphql-cop to probe depth limits, token limits, directive limits, and fragment-cycle handling. Map every path that exceeds the default limits.

7. Injection. Test every String and JSON argument with a SQL or NoSQL injection payload. Test resolver-level error responses for stack-trace disclosure.

8. CSRF and CORS. Confirm POST-only enforcement, content-type allowlist, and CSRF preflight requirement. Confirm the Origin allowlist is not wildcarded.

9. Subscription and persisted-query review. Confirm subscriptions re-check authorization at message dispatch time. Confirm persisted-query allowlist is enforced rather than advisory.

10. Reporting. Map every finding to OWASP API Security Top 10 (2023). Where the finding overlaps a CVE class (introspection / SuiteCRM, BOLA / Shopify HackerOne #2207248, BFLA / Hasura CVE-2022-46792, alias DoS / Directus CVE-2024-39895), cite the analogous public anchor so the reader can audit severity.

How to defend a GraphQL API: a layered stack

The defenses cluster across seven layers. None of them is sufficient alone. The diagram below summarizes the controls that should sit at each layer.

Figure 5: Seven-tier GraphQL defender stack. Sources: OWASP GraphQL Cheat Sheet, OWASP API Security Top 10 (2023), Apollo Router request-limits documentation, Hot Chocolate v15 security overview, Hasura security guide.

The seven layers, with the canonical control at each:

1. Edge. Per-IP and per-token rate limits, WAF rules that flag batch payloads, request-size and timeout budgets. The edge is the cheapest layer at which to drop a depth-bomb attack.

2. Transport. POST-only, application/json only, CSRF preflight (Apollo csrfPrevention or equivalent), TLS 1.3. Reject GET-encoded queries except for explicitly whitelisted persisted-query reads.

3. Parser. Maximum recursion depth, maximum tokens per document, maximum directive count, maximum alias count, fragment-cycle detection, and a hard cap on raw query size. These limits run before validation, which is the lesson Hot Chocolate CVE-2026-40324 made expensive: a parser-level crash bypasses the validator.

4. Validator. Depth limits, complexity / cost analysis, persisted-query allowlist, disabled introspection in production, disabled field suggestions in production. GraphQL Armor implements many of these as an Apollo / Yoga middleware.

5. Resolver. Field-level authorization on every id argument, input-shape allowlists for mutations, no mass assignment, graphql-shield or analogous policy plumbing, DataLoader for repeated reads.

6. Datastore. DataLoader batching, parameterized queries, per-tenant row-level security policies, query timeouts in the database.

7. Observability. Operation-name logging, alias-count and depth metrics, anomaly alerts on slow queries, persisted-query analytics, integration with the SIEM. The Wallarm 2025 ThreatStats finding that "no GraphQL-specific breaches" appeared in Q2 2025 is an observability problem at least as much as a vulnerability problem.

What this means for security buyers and CISOs

Three practical implications for any team running GraphQL in production.

1. GraphQL does not need a separate security tool. It needs OWASP API Security Top 10 (2023) controls applied to a different protocol. Most of the vulnerability classes in this post (BOLA, BFLA, BOPLA, injection, CSRF) are the same classes that affect REST. A web application penetration test that already exercises those classes against your REST endpoints can extend to your GraphQL endpoint with modest scope expansion. Stingrai's web application penetration testing service maps tests to OWASP API Top 10 categories and produces evidence per finding.

2. Continuous testing is more useful than annual testing. GraphQL libraries ship parser CVEs at a rate of two or three per year. A team that ran a pentest in March 2025 and missed the April 2025 disclosures of GitLab CVE-2025-3922 and Apollo Router CVE-2025-32032 had a six-to-twelve-month exposure window. A PTaaS engagement with quarterly retesting catches these regressions inside the patch window rather than after it.

3. Compliance posture and GraphQL hardening overlap. SOC 2 CC6.1, ISO 27001 A.8.25, PCI DSS 4.0 6.4.2, and NIS2 article 21 all require input validation, authentication, and authorization controls that map cleanly to OWASP API Security Top 10 (2023) controls. Stingrai's compliance and audit-readiness work includes GraphQL endpoints in scope by default for any client running a modern web stack.

GraphQL has matured into a default for high-traffic APIs. The Wallarm and Postman 2025 numbers (70% and 33% adoption respectively) put it on roughly the same footing as gRPC for internal traffic and ahead of OData for external. The protocol is well-engineered and the canonical libraries are well-maintained. The vulnerabilities that show up in pentests and CVE feeds are not novel. They are familiar API authorization, resource-management, and configuration mistakes presented through a different surface. The defender's task is straightforward in shape and laborious in execution: layer the controls, instrument the layer, and review the boundary regularly.

Frequently Asked Questions

What are the most common GraphQL API vulnerabilities?

The enduring classes are: introspection enabled in production (schema disclosure), Broken Object-Level Authorization (BOLA / IDOR via id arguments, OWASP API1:2023), Broken Function-Level Authorization (BFLA, OWASP API5:2023; Hasura CVE-2022-46792 is a clean example), mass assignment / BOPLA (OWASP API3:2023), batching and alias abuse (one HTTP request, N resolver calls; Directus CVE-2024-39895 multiplied database load), query depth and complexity DoS (graphql-java CVE-2023-28867, Hot Chocolate CVE-2026-40324, Apollo Router CVE-2025-32032, GitLab CVE-2025-3922), field-suggestion information disclosure (Clairvoyance reconstructs schemas even with introspection disabled), CSRF on GraphQL endpoints (Apollo Server 2 graphql-upload, GHSA-2p3c-p3qw-69r4), GraphQL injection (SQLi/NoSQLi via resolvers), and persisted-query allowlist bypass. Real-world bug bounty disclosures, including Shopify HackerOne #2207248 (US$5,000 IDOR on the BillingDocumentDownload and BillDetails GraphQL queries), repeatedly anchor BOLA and authorization classes as the most-paid GraphQL bugs.

Should GraphQL introspection be disabled in production?

Yes for any non-public API. Introspection lets a single __schema query return the full type system: every type, every field, every argument, every input-object shape, every mutation, every directive, and the description text developers write inline. Tools like GraphQL Voyager and Doyensec's InQL render that output as an attack graph in seconds. Apollo Server, Hot Chocolate, Hasura, and graphql-go all expose a config flag that disables introspection in production builds; SuiteCRM CVE-2023-47643 is the cautionary tale, where introspection was enabled by default in versions before 8.4.2. Note that disabling introspection is necessary but not sufficient: Clairvoyance and similar tools reconstruct schemas from field-suggestion errors, so disable field suggestions in production too.

What is a GraphQL batching attack?

A batching attack uses GraphQL's ability to send multiple operations or aliased fields in a single HTTP request to bypass per-request rate limits and authentication safeguards. The attacker sends one HTTP POST containing many queries (or many aliases of the same query), and the server executes all of them as if they were independent requests. Practical effects include credential brute-forcing (login mutation aliased 100 times in one POST), 2FA / OTP brute force, coupon-code enumeration, and resource-exhaustion DoS. Directus CVE-2024-39895 was a batching / aliasing vulnerability with a CVSS 6.5 score; an authenticated user could multiply database load linearly with the alias count by repeating a complex relational resolver in one request. Fix: deduplicate resolver invocations within a request, cap the alias count and operation count per request, and rate-limit by operation name plus token rather than by HTTP request alone.

How do attackers exploit GraphQL's depth and complexity?

GraphQL schemas often allow recursive type relationships (User → posts → author → posts → author ...). Without depth, complexity, or token limits, an attacker can craft a query whose execution plan grows exponentially, exhausting CPU, memory, or database connections. graphql-java CVE-2023-28867 lacked recursion-depth limits, allowing unauthenticated attackers to crash the JVM via stack overflow. Hot Chocolate CVE-2026-40324 demonstrated that even a 40 KB document could trigger a stack overflow in Utf8GraphQLParser before validation rules ran. Apollo Router CVE-2025-32032 showed that recursive fragments could expand uncontrollably during query planning, exhausting the Rust thread pool. Defenses: max recursion depth, max tokens, max alias count, max directive count, query-cost analysis (Apollo Router request-limits, GraphQL Armor, graphql-shield), persisted-query allowlists for clients you control, and parser-level limits before validator-level limits.

Is GraphQL more secure than REST?

Neither protocol is inherently more secure. GraphQL changes the attack surface; it does not shrink it. The single endpoint reduces inventory drift (an OWASP API9:2023 win) but also obscures per-operation visibility for traditional security controls. The strong type system catches some classes of bug at schema time but introduces new classes (introspection, aliasing, fragment recursion, depth attacks). The Wallarm 2025 API ThreatStats Report notes that the absence of GraphQL-specific breaches in Q2 2025 likely reflects detection gaps rather than safety. The honest framing: REST and GraphQL share most of the same vulnerability classes (BOLA, BFLA, mass assignment, injection, CSRF), and GraphQL adds depth / complexity DoS and introspection on top.

How do I test a GraphQL API for vulnerabilities?

Start with introspection. If __schema returns the type system, dump it with Doyensec's InQL or Apollo Sandbox, render it with GraphQL Voyager, and trace paths from public roots to sensitive types. Test BOLA on every id argument by querying with foreign IDs. Test BFLA by invoking admin-only mutations with a low-privilege token. Test BOPLA by passing input-object fields that are not in the public form (role, isAdmin, balance). Run graphql-cop for an automated baseline. Run BatchQL to test alias and batching limits. Run Clairvoyance to confirm field-suggestion exposure. Run depth and complexity probes (deeply nested queries, fragment cycles, directive overload). For production-grade testing, engage a PTaaS provider that documents GraphQL methodology against the OWASP API Security Top 10 (2023) and OWASP Web Security Testing Guide; Stingrai's web application penetration testing service maps tests to API1 through API10 and produces evidence for each finding.

What CVEs have affected major GraphQL libraries?

Documented CVEs and GHSAs across major GraphQL libraries include: GHSA-2p3c-p3qw-69r4 (Apollo Server 2 graphql-upload CSRF, May 2022), CVE-2022-46792 (Hasura GraphQL Engine row-level authorization in Update Many, December 2022), CVE-2023-28867 (graphql-java unbounded recursion DoS, March 2023), CVE-2023-26144 (graphql-js OverlappingFieldsCanBeMergedRule DoS, September 2023), CVE-2023-47643 (SuiteCRM unauthenticated GraphQL introspection, November 2023), CVE-2023-49559 (gqlparser directive-overload DoS, December 2023), CVE-2024-23841 (Apollo Next.js SSR XSS via JSON injection, January 2024), CVE-2024-39895 (Directus GraphQL alias DoS, July 2024), CVE-2024-47614 (async-graphql directive-overload DoS, September 2024), CVE-2025-3922 (GitLab GraphQL API resource exhaustion, April 2025), CVE-2025-32032 (Apollo Router recursive fragment DoS, April 2025), and CVE-2026-40324 (ChilliCream Hot Chocolate Utf8GraphQLParser stack overflow). Every entry is verifiable on nvd.nist.gov or the GitHub Security Advisory database.

How does CSRF work against a GraphQL API?

Classic CSRF requires three conditions: the server accepts state-changing requests via simple content types (text/plain, application/x-www-form-urlencoded, multipart/form-data) which browsers do not preflight; the server relies on cookies for authentication; and the attacker can lure a victim to a page that submits a form to the GraphQL endpoint. GraphQL servers that accept GET-encoded queries or that accept multipart/form-data without a CSRF check are at risk. Apollo Server 2's bundled graphql-upload library was vulnerable in this way (GHSA-2p3c-p3qw-69r4) because multipart/form-data POSTs from cross-origin pages do not trigger preflight. The fix in Apollo Server 4 and later defaults csrfPrevention to true, which requires either an X-Apollo-Operation-Name header or an Apollo-Require-Preflight header before executing operations. Apply equivalent preflight checks in any GraphQL server you ship.

What defenses should every GraphQL deployment have?

Layer the controls. At the edge: per-IP and per-token rate limits, a WAF rule that flags batch payloads, request-size and timeout budgets. At the transport layer: POST-only, application/json only, CSRF preflight, TLS 1.3. At the parser: max recursion depth, max tokens, max directives, max alias count, fragment-cycle detection, query-size cap. At the validator: depth limits, complexity / cost analysis, persisted-query allowlist, disabled introspection in production. At the resolver: field-level authorization on every id argument, input-shape allowlists for mutations, no mass assignment. At the datastore: DataLoader batching, parameterized queries, per-tenant row-level security, query timeouts in the database. At the observability layer: operation-name logging, alias-count and depth metrics, anomaly alerts on slow queries, and persisted-query analytics. The OWASP GraphQL Cheat Sheet, Apollo Router request-limits documentation, and Hot Chocolate v15 security overview are the canonical references.

Where can I learn more about GraphQL security?

Primary sources: the OWASP GraphQL Cheat Sheet, the OWASP API Security Top 10 (2023), the GraphQL specification, the PortSwigger Web Security Academy GraphQL labs, NCC Group's GraphQL whitepapers, Doyensec's GraphQL research blog (and InQL / GQLSpection), Trail of Bits' Apollo Server hardening guides, Apollo's own security documentation, Hasura's security guide, and the ChilliCream Hot Chocolate v15 security overview. For attack-surface telemetry, the Wallarm 2025 API ThreatStats Report, Akamai's State of the Internet API report, the Postman 2025 State of the API Report, and Escape's State of GraphQL Security 2024 are the most useful published datasets. For real-world exploitation, the curated reddelexc/hackerone-reports list of top GraphQL findings is the best free resource. Stingrai's own PTaaS and web application penetration testing practices map GraphQL methodology against the OWASP API Security Top 10.

References

1. OWASP. OWASP API Security Top 10 (2023). https://owasp.org/API-Security/editions/2023/en/0x11-t10/. Authoritative ranking of API vulnerability classes used to map every section of this article.

2. OWASP. GraphQL Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html. Canonical defensive guidance for GraphQL deployments.

3. National Vulnerability Database. CVE-2022-46792 Detail. https://nvd.nist.gov/vuln/detail/CVE-2022-46792. Hasura GraphQL Engine row-level authorization flaw in Update Many API (December 2022).

4. National Vulnerability Database. CVE-2023-26144 Detail. https://nvd.nist.gov/vuln/detail/CVE-2023-26144. graphql-js OverlappingFieldsCanBeMergedRule DoS (September 2023).

5. National Vulnerability Database. CVE-2023-28867 Detail. https://nvd.nist.gov/vuln/detail/CVE-2023-28867. graphql-java unbounded recursion DoS (March 2023).

6. National Vulnerability Database. CVE-2023-47643 Detail. https://nvd.nist.gov/vuln/detail/CVE-2023-47643. SuiteCRM unauthenticated GraphQL introspection (November 2023).

7. National Vulnerability Database. CVE-2023-49559 Detail. https://nvd.nist.gov/vuln/detail/CVE-2023-49559. gqlparser directive overload DoS (December 2023).

8. National Vulnerability Database. CVE-2024-23841 Detail. https://nvd.nist.gov/vuln/detail/CVE-2024-23841. Apollo experimental Next.js SSR XSS via JSON injection (January 2024).

9. National Vulnerability Database. CVE-2024-39895 Detail. https://nvd.nist.gov/vuln/detail/CVE-2024-39895. Directus GraphQL alias / field-duplication DoS (July 2024).

10. National Vulnerability Database. CVE-2025-32032 Detail. https://nvd.nist.gov/vuln/detail/CVE-2025-32032. Apollo Router recursive fragment DoS (April 2025).

11. GitLab Advisory Database. CVE-2024-47614: async-graphql Directive Overload. https://advisories.gitlab.com/pkg/cargo/async-graphql/CVE-2024-47614/. Rust async-graphql directive-overload DoS (September 2024).

12. GitLab Advisory Database. CVE-2026-40324: ChilliCream GraphQL Platform Utf8GraphQLParser Stack Overflow. https://advisories.gitlab.com/nuget/hotchocolate.language/CVE-2026-40324/. ChilliCream Hot Chocolate parser stack overflow (Q1 2026).

13. SentinelOne Vulnerability Database. CVE-2025-3922: GitLab GraphQL API DOS Vulnerability. https://www.sentinelone.com/vulnerability-database/cve-2025-3922/. GitLab GraphQL API CWE-770 unrestricted resource consumption (April 2025).

14. GitHub Security Advisory. GHSA-2p3c-p3qw-69r4: The graphql-upload library included in Apollo Server 2 is vulnerable to CSRF mutations. https://github.com/apollographql/apollo-server/security/advisories/GHSA-2p3c-p3qw-69r4. Apollo Server 2 graphql-upload CSRF (May 2022).

15. GitHub Security Advisory. GHSA-g7mj-g7f4-hgrg: Critical vulnerability impacting Hasura GraphQL Engine v2.10.0 to v2.15.1. https://github.com/hasura/graphql-engine/security/advisories/GHSA-g7mj-g7f4-hgrg. Hasura advisory paired with CVE-2022-46792.

16. HackerOne (Shopify program). IDOR on GraphQL queries BillingDocumentDownload and BillDetails. https://hackerone.com/reports/2207248. Disclosed 2024; bounty US$5,000.

17. HackerOne (Shopify program). GraphQL Introspection Enabled on Storefront. https://hackerone.com/reports/2886723. Schema disclosure on a Shopify storefront GraphQL endpoint.

18. HackerOne (GitLab program). CSRF on /api/graphql allows actions against attacker-chosen account. https://hackerone.com/reports/1122408. CSRF disclosure against GitLab's GraphQL endpoint.

19. HackerOne (GitHub program). CSRF protection bypass in GitHub. https://hackerone.com/reports/1497169. CSRF protection bypass disclosure.

20. HackerOne. How a GraphQL Bug Resulted in Authentication Bypass. https://www.hackerone.com/blog/how-graphql-bug-resulted-authentication-bypass. Editorial walkthrough of a public auth-bypass disclosure.

21. reddelexc. hackerone-reports / tops_by_bug_type / TOPGRAPHQL.md. https://github.com/reddelexc/hackerone-reports/blob/master/tops_by_bug_type/TOPGRAPHQL.md. Curated list of top GraphQL bug bounty disclosures.

22. Wallarm. Wallarm Annual 2025 API ThreatStats Report. https://www.wallarm.com/reports/2025-api-security-report. 70% of organizations use GraphQL; 50%+ of CISA KEV catalog entries API-related.

23. Wallarm Lab. The API Security Reality Check: Key Takeaways from Q2 2025 API ThreatStats Report. https://lab.wallarm.com/api-security-reality-check-key-takeaways-from-q2-2025-api-threatstats-report/. GraphQL-specific breach detection commentary.

24. Akamai. State of the Internet 2024: Lurking in the Shadows API Security Trends. https://www.akamai.com/lp/soti/lurking-in-the-shadows. ~150 billion API attacks Jan 2023 through Dec 2024; OWASP API Security Top 10 incidents up 32% YoY.

25. Akamai. Akamai Research: Web Attacks Up 33%, APIs Emerge as Primary Targets. https://www.akamai.com/newsroom/press-release/akamai-research-web-attacks-up-33-apis-emerge-as-primary-targets. Macro press release accompanying the SOTI dataset.

26. Postman. 2025 State of the API Report. https://www.postman.com/state-of-api/2025/. GraphQL adoption at 33%; webhooks 50%; WebSockets 35%.

27. Escape. The State of GraphQL Security 2024. https://escape.tech/blog/the-state-of-graphql-security-2024/. 160 endpoints, 3,835 operations, 13,720 issues, 4,527 critical, 69% DoS-susceptible.

28. PortSwigger. Web Security Academy: GraphQL API vulnerabilities. https://portswigger.net/web-security/graphql. Lab-based exploration of introspection, BOLA, brute-force protection bypass, and field-exposure flaws.

29. PortSwigger. GraphQL introspection enabled (Knowledge Base). https://portswigger.net/kb/issues/00200512_graphql-introspection-enabled. Severity guidance and detection notes.

30. Apollo GraphQL. Cross-Site Request Forgery (CSRF) Prevention. https://www.apollographql.com/docs/graphos/routing/security/csrf. Canonical configuration for the Apollo Router preflight requirement.

31. Apollo GraphQL. Request Limits. https://www.apollographql.com/docs/graphos/routing/security/request-limits. Recursion-depth, query-size, and complexity limits in the Apollo Router.

32. Apollo GraphQL. Graph Security Overview. https://www.apollographql.com/docs/graphos/platform/security/overview. Production-hardening checklist.

33. Hasura. Critical Vulnerability in Hasura's GraphQL Engine v2.10.0. https://hasura.io/blog/critical-vulnerability-in-hasuras-graphql-engine-v2-10-0. Vendor disclosure paired with CVE-2022-46792.

34. ChilliCream. Hot Chocolate v15 Security Overview. https://chillicream.com/docs/hotchocolate/v15/security/. Defense-in-depth guidance for the .NET GraphQL stack.

35. Doyensec. InQL: A Burp Extension for GraphQL Security Testing. https://github.com/doyensec/inql. Tooling for schema dump, attack-graph rendering, and authorization probing.

36. Doyensec. GQLSpection: Schema parser and query generator. https://github.com/doyensec/GQLSpection. Companion tool for systematic mutation invocation.

37. IvanGoncharov. GraphQL Voyager. https://github.com/IvanGoncharov/graphql-voyager. Visualization of GraphQL schemas as interactive graphs.

38. Dolev Farhi. graphql-cop. https://github.com/dolevf/graphql-cop. Automated GraphQL security audit tool.

39. Assetnote. BatchQL. https://github.com/assetnote/batchql. Tool for testing GraphQL batching attacks.

40. Nikita Stupin. Clairvoyance: Schema reconstruction via field suggestions. https://github.com/nikitastupin/clairvoyance. Reconstructs GraphQL schemas when introspection is disabled.

41. gsmith257-cyber. GraphCrawler. https://github.com/gsmith257-cyber/GraphCrawler. Automation around GraphQL security tooling.

42. Trail of Bits. Secure your Apollo GraphQL server with Semgrep. https://blog.trailofbits.com/2023/08/29/secure-your-apollo-graphql-server-with-semgrep/. Static-analysis rules for common Apollo misconfigurations.

43. Cybersecurity News. GraphQL Security Report 2024: 69% of API Services Were Susceptible to DoS Attacks. https://cybersecuritynews.com/graphql-security-2024-report/. Corroborates Escape's headline DoS finding.

44. DailyCVE. Directus, GraphQL Field Duplication Denial of Service (DoS), CVE-2024-39895. https://dailycve.com/directus-graphql-field-duplication-denial-of-service-dos-cve-2024-39895-medium/. Editorial summary of the Directus alias DoS bug.

45. OpenAI / Cybersecurity News. Apollo Router Critical Flaw Leaves Federated GraphQL Systems Vulnerable. https://undercodenews.com/cve-critical-flaw-in-apollo-router-leaves-federated-graphql-systems-vulnerable/. Coverage of Apollo Router CVE-2025-32032.