Challenges of GraphQL security in 2024

Challenges of GraphQL security in 2024

Speakers: Tristan Kalos (Co-founder and CEO, ESCAPE), Antoine Carossio (Co-founder and CEO, ESCAPE)

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=O9V3CFUiN3g

Overview

In "Challenges of GraphQL security in 2024," Tristan Kalos and Antoine Carossio, co-founders of the API security company ESCAPE, presented exclusive research from their "State of GraphQL Security 2024" report. The talk delved into the unique security landscape of GraphQL APIs, highlighting the vulnerabilities uncovered through large-scale penetration testing of 160 production GraphQL services belonging to various companies worldwide. Their findings reveal a significant and escalating challenge in securing this increasingly popular API technology.

The core of their presentation focused on why GraphQL presents distinct security hurdles compared to traditional REST APIs, detailing both classic API vulnerabilities that persist and novel attack vectors specific to GraphQL's architecture. They demonstrated that despite its benefits for developers, GraphQL's powerful features, if misconfigured or misunderstood, can lead to severe security flaws, including data exposure, unauthorized access, and widespread denial-of-service (DoS) vulnerabilities. The speakers emphasized a critical gap in developer understanding regarding GraphQL-specific security best practices, leading to a proliferation of easily exploitable weaknesses.

This research is particularly pertinent as GraphQL continues to gain traction within enterprises, often serving as a unified gateway for multiple underlying services. The talk provides a stark warning about the current state of GraphQL security, offering valuable insights for both red and blue teams. It underscores the necessity for specialized tools and methodologies to effectively secure GraphQL deployments, advocating for proactive measures and better developer education to mitigate the pervasive risks identified in their comprehensive study.

Background

▶ Watch: Introduction and overview of GraphQL security research (0:00)

GraphQL has experienced a significant surge in adoption, particularly among Fortune 500 companies, due to its compelling capabilities. It allows developers to aggregate all their APIs into a single endpoint, providing a flexible and efficient language for querying data. This approach simplifies front-end development and reduces over-fetching or under-fetching of data, making it highly attractive for modern application architectures. However, this flexibility and power come with a complex security overhead that many organizations are struggling to address.

The inherent design of GraphQL introduces several challenges that make it uniquely vulnerable. Firstly, as a full-featured language, every specific feature within a GraphQL query (such as operations, arguments, or directives) can introduce its own set of potential vulnerabilities. Secondly, GraphQL organizes resources as a graph, meaning that a single resource might be accessible via multiple paths. This graph-like structure makes implementing robust access control a "real nightmare," as Antoine Carossio explained, requiring protection not just on one path but on all possible paths leading to a sensitive resource.

ESCAPE's research builds upon their prior work in API security, including "The State of Public APIs 2023" and "The State of API Security: The API Security Secrets Pro" report. For their "State of GraphQL Security 2024" study, they undertook an ambitious project: analyzing 160 production GraphQL APIs from companies across the globe. This extensive study involved 98 scanning and computation hours, ultimately uncovering over 13,000 security alerts, averaging 87 security issues per GraphQL API. This figure, as Tristan Kalos noted, is a significant increase—three times the amount found in their 2023 study—indicating that the problem is not only persistent but growing.

A key aspect of their methodology was the development of a proprietary algorithm called Feedback Driven API Expression. Traditional vulnerability scanners often fail to adequately test GraphQL APIs because their generated requests are typically blocked at the application validation layer, resulting in "random fuzzing" that doesn't align with the API's business logic. ESCAPE's approach, rooted in reinforcement learning, aims to intelligently explore the GraphQL graph. By understanding the API's business logic and inputting real, valid data (e.g., actual user IDs, emails, and potential password injections), their algorithm can construct sequences of requests that are far more likely to expose genuine business logic flaws and traverse all relevant, recursive paths within the API's graph structure. This sophisticated testing methodology was crucial for uncovering the deep-seated vulnerabilities discussed in the talk.

Key Findings

▶ Watch: Why GraphQL is inherently vulnerable to cyber attacks (2:40)

The comprehensive study by ESCAPE unveiled a staggering number of security issues across the analyzed GraphQL endpoints. A total of 30,720 security issues were identified, with over 4,000 of these classified as highly critical. This translates to an average of 87 issues per GraphQL service, a figure that alarmingly represents a threefold increase compared to ESCAPE's previous 2023 findings, underscoring a deepening crisis in GraphQL security.

The top vulnerabilities identified paint a clear picture of the prevalent risks:

• Unrestricted resource consumption capabilities: A common issue allowing attackers to exhaust server resources.
• Mixed configurations: Indicating misconfigurations that often expose sensitive functionalities.
• Broken Function Level Authorization (BFLA): Permitting unauthorized users to access or perform actions they shouldn't.
• Server-Side Request Forgeries (SSRF): Enabling attackers to make the server initiate requests to arbitrary domains.
• Unsafe consumption of APIs: Often related to how GraphQL acts as a gateway to underlying, less secure APIs.

Beyond these common categories, the research highlighted that classic API vulnerabilities are far from absent in GraphQL applications. Verbose error messages were a significant concern, frequently exposing internal details such as package version numbers—information easily leveraged by attackers to find known vulnerabilities. More critically, when GraphQL acts as an aggregator for underlying APIs, errors can surface internal stack traces containing DWT tokens or other credentials, often leading to unauthorized internal access. Access control issues were rampant, with many mutations (GraphQL's equivalent of POST requests for modifying data) being accessible without any authorization token, allowing anyone to alter database states. Furthermore, traditional injection flaws persist, with the team finding two instances of XML External Entity (XXE) injections and no less than 21 cases of JWT none algorithm injection, a well-known vulnerability allowing attackers to bypass authentication by crafting tokens with a "none" algorithm.

However, the most concerning findings were those specific to GraphQL's unique architecture:

1. API Schema Leak: While many organizations disable introspection (the ability to query the GraphQL schema), the study found that GraphQL's default field suggestion feature (which corrects typos) can be exploited. By fuzzing and observing these suggestions, attackers can reconstruct the entire API schema. In one real-life scenario, this led to the discovery of an updateAdmin mutation that was completely unprotected, allowing an attacker to change the admin password of a SaaS platform without any authentication.

1. Denial-of-Service (DoS) via Recursive Fragments: GraphQL fragments are reusable pieces of logic, akin to functions. An attacker can craft a query where a fragment calls itself, creating an infinite recursive loop that can easily crash a misconfigured GraphQL server with a single, simple request.

1. Brute-Forcing via Batching: GraphQL allows sending multiple queries within a single HTTP request. This feature, while useful for efficiency, can bypass HTTP-level rate limitation. An attacker can embed thousands of login attempts with different credentials into one HTTP request, effectively circumventing traditional WAFs and leading to stolen accounts or further DoS.

1. GraphQL Bombs: This novel vulnerability, discovered by ESCAPE's research team, leverages GraphQL's file upload mechanism and alias system. By uploading a small file (e.g., 2MB) and using multiple aliases pointing to the same file within the GraphQL query, the server can be tricked into expanding this data exponentially on the server side (e.g., 1GB), leading to storage saturation and DoS. This vulnerability is aptly named after the classic "zip bomb."

Overall, the report concludes that 33% of API services exhibit highly critical vulnerabilities, and over 72% are vulnerable to at least medium-level issues. A staggering 69% of GraphQL endpoints are susceptible to denial-of-service attacks, which is particularly alarming given GraphQL's role as a single entry point for many external APIs. The good news, however, is that 80% of these issues are resolvable by implementing fundamental best practices such as robust access control, input validation, and proper rate limiting, indicating a significant lack of understanding among development teams regarding GraphQL-specific security requirements.

Technical Deep Dive

▶ Watch: ESCAPE's Feedback Driven API Expression pen-testing methodology (5:50)

The technical depth of the vulnerabilities discussed by Tristan Kalos and Antoine Carossio highlights the intricate challenges in securing GraphQL applications. ESCAPE's methodology, particularly their Feedback Driven API Expression algorithm, is central to understanding how these deep-seated flaws were uncovered. Unlike traditional scanners that perform "random fuzzing" and get "stuck at the application validation layer," Feedback Driven API Expression employs a reinforcement learning technique. This algorithm is designed to "explore the GraphQL graph smartly," understanding the API's business logic to generate meaningful requests. For instance, instead of just fuzzing a user ID field with random strings, it inputs "real data" previously found in the API, such as legitimate user IDs, emails, or even crafted passwords with injection payloads. This allows the scanner to make "sequences of requests that have a chance... to test the business logic of an application" and recursively traverse relevant paths within the complex graph structure.

Delving into the GraphQL-specific vulnerabilities, the mechanisms are particularly insightful:

1. API Schema Leak (via Field Suggestion): While disabling introspection is a common security practice to hide the API's internal structure, GraphQL's helpful "field suggestion" feature inadvertently undermines this. When a user makes a typo in a query (e.g., create session instead of createSession), the GraphQL server responds with suggestions like "Did you mean createSession, createUser, createFile, or createImage?". By systematically fuzzing input fields and analyzing these error messages, an attacker can incrementally reconstruct the entire API schema, even without introspection. The open-source tool Clairvoyance (mentioned as being maintained by ESCAPE) automates this process, demonstrating how a full schema can be rebuilt in real-life applications. The danger here is amplified because developers often assume that disabling introspection is sufficient, leading them to poorly protect functions that are "hidden" but still discoverable. The updateAdmin mutation found in the study, exploitable without an access token, is a prime example of this false sense of security.

1. Denial-of-Service (DoS) with Recursive Fragments: This vulnerability exploits GraphQL's fragments, which are reusable sets of fields. Analogous to functions in programming, fragments allow for modular query construction. A malicious actor can define a fragment that recursively calls itself, for example:

When such a query is executed on a GraphQL server without proper depth limiting or complexity analysis, it creates an "infinite recursive loop." The server attempts to resolve the fragment indefinitely, consuming CPU and memory resources until it crashes, resulting in a simple yet effective DoS attack.

1. Brute-Forcing by Bypassing Rate Limits: GraphQL's ability to process "multiple queries in one single HTTP request" (often called batching) is a performance feature that becomes a security weakness when combined with HTTP-level rate limitation. If a web application firewall (WAF) or API gateway only rate-limits HTTP requests, an attacker can craft a single HTTP POST request containing hundreds or thousands of distinct GraphQL operations (e.g., login mutations with different username/password combinations). This single HTTP request counts as one against the rate limit, but internally, the GraphQL server processes all the embedded operations. This allows attackers to perform massive brute-forcing attacks against login endpoints, potentially leading to account compromise, sensitive data exfiltration, or resource exhaustion.

1. GraphQL Bombs: This particularly insidious DoS vector leverages the combination of file uploads and GraphQL's alias system. When uploading files in GraphQL, a multipart data request is used, where the GraphQL query references the file data via a pointer. The vulnerability arises when an attacker uses multiple aliases in the GraphQL query, all pointing to the same uploaded file. For example:

If the server's GraphQL engine simply expands each alias by copying the referenced file data, a small 2MB uploaded file could be expanded "x times where x is the number of alias that you made" into gigabytes of data on the server's disk or memory (e.g., a 1GB expansion). This rapid and massive resource consumption can quickly lead to storage saturation or memory exhaustion, causing a severe DoS. The vulnerability's name, "GraphQL bomb," is a clear nod to the "zip bomb" concept, where a small compressed file unpacks into an enormous uncompressed size.

These technical explanations underscore that securing GraphQL requires an understanding that goes beyond generic API security principles. It demands specific knowledge of GraphQL's language features, its execution model, and how these can be manipulated for malicious purposes.

Demo / Proof of Concept

▶ Watch: Shocking overall findings from large-scale GraphQL study (7:50)

While the talk itself did not feature a live, interactive demonstration of exploiting these vulnerabilities, the speakers extensively referenced and provided access to several practical tools and resources that function as tangible proofs of concept and learning environments. These resources are invaluable for both red teams looking to exploit GraphQL APIs and blue teams aiming to understand and defend against such attacks.

One key resource mentioned is a dedicated playground that ESCAPE provides. This playground is designed to illustrate how the various vulnerabilities discussed in the talk—such as schema leaks, DoS attacks, and brute-forcing—can be exploited in a controlled environment. Crucially, it also demonstrates how these vulnerabilities can be remediated using different configuration parameters of GraphQL Armor, their open-source security solution. This allows users to experiment hands-on with both the attack vectors and the defensive countermeasures.

Furthermore, the speakers highlighted several other open-source tools that serve as practical demonstrations of the concepts:

• Clairvoyance: This tool directly demonstrates the API schema leak vulnerability. It allows users to automatically rebuild a GraphQL schema from the server's field suggestion feature, even when introspection is disabled. This is a direct proof that relying solely on disabling introspection is insufficient for security.
• GraphQL Voyager: Mentioned as being used multiple times in the presentation to visualize the graph structure of a GraphQL application, GraphQL Voyager is an open-source tool that helps developers and hackers alike explore an API's schema. By pasting an introspection result (or one rebuilt by Clairvoyance), users can visually navigate the graph, making it easier to identify potential attack paths and understand data relationships.
• Goctopus: This tool, written in Go, was used by ESCAPE to discover GraphQL API endpoints on target domains. It's a proof of concept for API discovery, showing how attackers (and researchers) can find hidden GraphQL services within a company's infrastructure by simply inputting a domain name.
• GraphQL Academy: Described as a "fully open source project," GraphQL Academy provides an interactive learning experience directly in the browser using web containers. It teaches the most common GraphQL security issues, allowing users to understand the vulnerabilities by seeing them in action and even examining the source code without needing to install any local development environment.

These tools, collectively, act as powerful proofs of concept, validating the existence and exploitability of the discussed vulnerabilities and offering concrete ways for individuals to learn, test, and defend against them.

Defensive Implications

▶ Watch: Top 10 most common GraphQL vulnerabilities identified (8:40)

The findings presented by ESCAPE underscore an urgent need for organizations to re-evaluate and strengthen their security posture for GraphQL APIs. The prevalence of critical vulnerabilities, many of which are easily preventable, points to a significant gap in current security practices and developer awareness. Defenders should prioritize the following actions:

1. Implement Specialized GraphQL Security Solutions: The most direct recommendation is to deploy GraphQL Armor. This open-source project is designed to prevent a wide array of common GraphQL security issues by default. It offers protections against recursive fragments (DoS), excessive query depth, complexity attacks, and other misconfigurations that lead to vulnerabilities. Its customizability allows organizations to tailor defenses to their specific application needs.

1. Robust Access Control and Authorization: This is paramount, especially for mutations. Every mutation should be rigorously protected with proper authentication and fine-grained authorization checks. The talk highlighted instances where mutations were accessible without any token, allowing unauthorized state changes. Implement attribute-based access control (ABAC) or role-based access control (RBAC) at the GraphQL resolver level to ensure users can only access or modify resources they are explicitly permitted to.

1. Comprehensive Input Validation: Sanitize and validate all inputs to GraphQL queries and mutations. This is crucial to prevent classic injection attacks, including XML External Entity (XXE) injections and other forms of code or command injection that can still occur within GraphQL contexts, as demonstrated by the discovery of XXE and JWT none algorithm injection vulnerabilities.

1. Application-Level Rate Limiting: Do not rely solely on HTTP-level rate limiting (e.g., from WAFs or API gateways) for GraphQL endpoints. Due to GraphQL's ability to batch multiple operations into a single HTTP request, HTTP-level limits can be easily bypassed for brute-forcing attacks. Implement rate limiting at the GraphQL query level, considering factors like query complexity, number of operations, and specific field access, to prevent resource exhaustion and credential stuffing.

1. Secure Error Handling: Configure GraphQL servers to avoid verbose error messages in production environments. Never expose internal stack traces, package version numbers, or sensitive internal tokens (like DWT tokens) to clients. Error messages should be generic and provide minimal information to an attacker, while detailed logs should be captured internally for debugging.

1. Schema Management and Protection: Understand that disabling introspection is not a complete solution for hiding the API schema. The field suggestion feature can still be used to reconstruct the schema (as demonstrated by Clairvoyance). While introspection can be disabled in production, security teams must assume the schema is discoverable and ensure that all fields, types, and mutations are properly protected, regardless of their visibility. Implement schema validation and integrity checks during the CI/CD pipeline.

1. DoS Prevention Mechanisms: Implement specific defenses against denial-of-service vectors unique to GraphQL:

• Query Depth Limiting: Restrict how deeply nested a query can be.
• Query Complexity Analysis: Assign a cost to each field and operation, rejecting queries that exceed a predefined complexity threshold.
• Resource Limits: Implement limits on the number of aliases allowed in file uploads to prevent GraphQL bombs. This might involve server-side validation of multipart data or limiting the total size of expanded data.

1. Regular Security Testing: Conduct specialized security assessments for GraphQL APIs. Generic vulnerability scanners are often insufficient. Tools and methodologies like ESCAPE's Feedback Driven API Expression are necessary to uncover business logic flaws and vulnerabilities that arise from the graph-like nature of GraphQL. Incorporate GraphQL-specific pen-testing tools (like Goctopus for discovery, GraphQL Voyager for exploration, and specialized wordlists for brute-forcing) into security testing regimens.

1. Developer Education: Address the "lack of understanding by the development teams of the best practices specifically for GraphQL." Provide training on secure GraphQL development, emphasizing the unique attack vectors and defensive strategies. Resources like GraphQL Academy can be invaluable for this purpose, offering hands-on learning for common security issues.

By adopting these comprehensive defensive strategies, organizations can significantly mitigate the severe risks posed by misconfigured and insecure GraphQL APIs, moving towards a more secure and resilient application ecosystem.

Key Takeaways

• GraphQL introduces unique attack vectors: Beyond traditional API vulnerabilities, GraphQL's powerful features like flexible querying, fragments, batching, and schema introspection create novel security challenges, leading to widespread and critical flaws.
• High prevalence of critical vulnerabilities: ESCAPE's research found over 30,000 security issues across 160 production GraphQL APIs, with 4,000+ highly critical and 69% vulnerable to denial-of-service, underscoring a significant security gap.
• GraphQL-specific vulnerabilities are potent: Key issues include API schema leaks (even with introspection disabled), denial-of-service via recursive fragments and "GraphQL bombs" (small files expanding into gigabytes), and rate limit bypasses via batched queries.
• Classic API flaws persist: Verbose error messages exposing internal details (including DWT tokens), widespread unauthorized mutations, and injection vulnerabilities (XXE, JWT none algorithm) continue to plague GraphQL implementations.
• Security requires specialized tools and knowledge: Generic API security approaches are insufficient. Effective defense demands an understanding of GraphQL's unique architecture and specialized tools like ESCAPE's Feedback Driven API Expression, GraphQL Armor, Clairvoyance, and GraphQL Academy.
• Many issues are easily preventable: A significant 80% of identified issues could be resolved by implementing fundamental best practices: robust access control, comprehensive input validation, application-level rate limiting, secure error handling, and careful schema management.

About the Speaker(s)

Tristan Kalos is the co-founder and CEO of ESCAPE, an API security company focused on helping security teams discover and secure their exposed single-page applications and APIs. An ex-researcher in artificial intelligence applied to cybersecurity, Tristan's personal experience of being hacked motivated him to establish a cybersecurity startup dedicated to addressing critical security challenges.

Antoine Carossio (also referred to as iCarossio in the transcript) is the co-founder and CEO of ESCAPE, working alongside Tristan Kalos. He graduated from UC Berkeley with Tristan and is a passionate open-source contributor, actively involved in various open-source projects including those discussed in the talk. Antoine also identifies as a "huge Apple fan."