Decoding GraphQL: How to Map Hidden Attack Surfaces

Decoding GraphQL: How to Map Hidden Attack Surfaces

Speakers: Antoine Carossio, Tristan Kalos

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch the full talk

Reading time: ~7 minutes

TL;DR

Tristan Kalos and Antoine Carossio, co-founders of the API security company Escape, scanned the top one million domains on the internet, discovered nearly 200,000 exposed GraphQL APIs, and found an average of 90 security issues per service — three times their 2023 findings. The root of the problem: GraphQL's graph-based architecture, federation model, and feature-rich query language create attack surfaces that standard REST-focused security programs consistently miss.

Introduction

GraphQL adoption is accelerating. Gartner estimates that 40% of enterprise companies will be using GraphQL within two years, up from roughly 10% in 2021. Major cloud providers — AWS with AppSync, Spotify replacing its REST API entirely in 2025 — are normalizing it as the default API layer. And yet most application security programs have not caught up, treating GraphQL endpoints with the same controls designed for HTTP REST APIs. The mismatch, according to Kalos and Carossio, is creating a sprawling and largely unmapped attack surface.

The two researchers presented results from their "State of GraphQL Security" report at BSidesSF 2025, combining a novel internet-scale scan methodology with a feedback-driven semantic testing algorithm specifically designed to find business logic vulnerabilities that standard fuzzing tools cannot reach.

Why GraphQL Is Structurally Different — and Harder to Secure

▶ Watch: GraphQL's unique security challenges (7:20)

Carossio opened with the architectural properties that make GraphQL uniquely difficult to secure:

Federation as an aggregation layer. A single GraphQL endpoint can federate multiple sub-graphs and back-end APIs, some of which are internet-facing and some of which are internal. When a developer assumes an internal API doesn't need hardened security because it's "not exposed to the internet," and that internal API is reachable through the public GraphQL gateway, the assumption becomes a vulnerability.

The graph makes access control a nightmare. GraphQL organizes data as a graph. Every path through that graph that leads to a sensitive resource must be secured at the same level. Missing a single edge or node means an attacker can reach data through an alternate graph traversal that the access control policy didn't anticipate.

Feature richness means attack richness. GraphQL supports depth, width, aliases, fragments, batching, directives, and parameterized queries — and each of these features carries its own exploitation potential. Unlike HTTP's GET/POST/PUT/DELETE verbs, which the entire security stack has been built around, GraphQL uses only queries (reads) and mutations (writes), a distinction the HTTP stack does not understand or enforce.

A quick demonstration illustrated the rate-limiting bypass: by wrapping multiple login attempts as separate GraphQL queries within a single HTTP request, an attacker can brute-force credentials while the server's HTTP-level rate limiter counts only one request.

The Scan Methodology: Discovering 200,000 GraphQL APIs at Internet Scale

▶ Watch: The discovery and scanning methodology (16:45)

The research team built a purpose-built open-source tool called Gtopus, written in Go, designed to perform all-in-one GraphQL discovery and fingerprinting. Starting from the Tranco top one million domain list (with sensitive government domains excluded to avoid interference), the workflow ran in three stages:

1. Subdomain enumeration to expand the attack surface from the root domain.
2. URL discovery to identify potential API endpoints among front-end assets and static resources.
3. GraphQL fingerprinting — sending targeted queries and analyzing response shapes to distinguish true GraphQL endpoints from false positives and honeypots, and extracting schema information (introspection) where available.

The result: approximately 200,000 GraphQL APIs exposed on the public internet, of which more than 60,000 had their schema (the GraphQL equivalent of an OpenAPI specification, defining the full data model) completely open. One-third of all discovered APIs had introspection enabled.

For the security testing phase, the team built a reinforcement learning algorithm that accepts both a service URL and its introspection schema. Standard fuzzing — whether random data or LLM-generated data — fails against GraphQL because random values don't pass data validation layers, meaning test requests never reach the business logic being tested. The Escape algorithm solves this by making semantically correct requests in a deliberate order: it calls a listHotels endpoint first to get a valid hotel ID, confirms room availability before booking, uses a registered test user's email — feeding real data from prior API responses back into subsequent requests.

What They Found: Vulnerabilities at Scale

▶ Watch: Research findings and vulnerability analysis (26:00)

The top OWASP API vulnerabilities found across the corpus were:

• Unrestricted resource consumption (most prevalent): GraphQL's query composition capabilities make it trivially easy to craft computationally expensive queries. Most APIs did not implement query depth limits, cost limits, or complexity budgets.
• Security misconfigurations: Basic configuration errors were widespread, suggesting that GraphQL-specific best practices are not well understood by developers or security teams.
• Broken function-level authorization (BFLA/BOLA): The graph data model complicates authorization at scale, and the data confirmed this — authorization failures across graph paths were common.

But the most interesting findings were GraphQL-specific:

Schema leaks via field suggestion. When introspection is disabled (a common security recommendation), many GraphQL servers still enable a "field suggestion" feature that corrects user typos. By systematically fuzzing field names and observing correction suggestions, the team rebuilt full schemas on endpoints where introspection was supposedly disabled. In one real case, a reconstructed schema revealed an updateAdmin mutation that was entirely unprotected — no authentication, no authorization — because the developer assumed that since it wasn't in the public schema, no one would find it. The team changed the admin password to demonstrate the impact.

Recursive fragment denial of service. GraphQL fragments — reusable query logic similar to functions — can be written to call themselves recursively. The server enters an infinite loop and crashes from stack exhaustion. The team achieved denial-of-service conditions on multiple production GraphQL servers with a single small request. A CVE was filed against the Juniper GraphQL service through this mechanism.

Batching for rate limit bypass. One HTTP request containing 1,000 login mutation attempts can brute-force credentials while HTTP-level rate limiting remains unaware. This is the attack demonstrated in the opening example.

GraphQL bombs. Exploiting aliasing and batching together: alias a one-megabyte file a thousand times in a single request. The server expands each alias server-side, instantiating one gigabyte of data from a one-megabyte payload — a storage-saturating denial-of-service attack.

Secret exposure at scale. The scan found more than 4,000 secrets in stack traces from GraphQL endpoints: 49 passwords, two credit card numbers, and approximately 1,396 access tokens. Stack traces are particularly dangerous in GraphQL federation — a back-end service that assumes it is internal may include verbose debug traces, which propagate through the gateway to public responses.

Defense Recommendations and Open-Source Tooling

The research team distilled their findings into a tiered remediation checklist. Quick wins include disabling stack traces in production and disabling introspection on public endpoints. GraphQL-specific controls at the medium tier include query depth limits, query cost limits, aliasing limits, and rate limiting that operates at the GraphQL query level rather than only at the HTTP level. For mature programs, the highest-value investments are field-level role-based access control, federation boundary hardening, and continuous automated testing using tools like Escape.

For teams wanting a quick start, Carossio demonstrated GraphQL Armor, an open-source security middleware that implements ten GraphQL security best practices in a single line of code. The project is battle-tested across Fortune 500 deployments and available on GitHub.

▶ Watch: GraphQL Armor open-source tool demo (38:00)

Notable Quotes

"GraphQL is everywhere and it's very vulnerable — and this is a blind spot in the AppSec programs of many companies."

— Tristan Kalos, ▶ 4:30

"With great powers comes also great responsibility. The whole HTTP stack has been built around GET, POST, PUT, DELETE — GraphQL doesn't have that."

— Antoine Carossio, ▶ 10:00

"We found almost 90 issues per GraphQL service — three times the amount we found in 2023."

— Tristan Kalos, ▶ 27:15

Key Takeaways

• Nearly 200,000 GraphQL APIs are publicly exposed on the internet; the average service has ~90 security issues, three times higher than 2023, driven by both improved tooling and a growing ecosystem with immature security practices.
• Standard REST-oriented security controls — HTTP-level rate limiting, conventional access control models, REST-specific AppSec tooling — are structurally inadequate for GraphQL's federated, graph-based architecture.
• Disabling introspection is not sufficient: field suggestion features allow schema reconstruction through targeted fuzzing, and "security by obscurity" in GraphQL consistently fails.
• GraphQL-specific attack classes — recursive fragment DoS, batching-based brute force, aliasing-based GraphQL bombs — are trivially executable against most production deployments.
• The open-source tools Gtopus (discovery and fingerprinting) and GraphQL Armor (one-line security middleware) provide immediate, low-friction starting points for teams assessing or hardening GraphQL exposure.