Background

In 2015, Meta released GraphQL as an open-source tool for web developers to access backend data structures without using traditional REST API infrastructure and conventions. In 2025, this technology has officially celebrated its 10th birthday, and a Gartner survey has identified that approximately 60% of enterprises are slated to use GraphQL in production deployments by 2027, doubling the current 30% adoption rate seen in 2024. But like many emerging technologies GraphQL is proving to be difficult to secure, with submissions of GraphQL vulnerabilities to the HPE Aruba Networking Infrastructure Bug Bounty program ramping up consequently. This begs the question – what is it about GraphQL that takes traditional web developers by surprise, and how are these vulnerabilities being used by attackers? In this short article, I aim to dive deep into the host of new challenges presented when developing with GraphQL, and how savvy penetration testers use these quirks to their advantage.

Before getting into its vulnerabilities, let’s break down the innovations that GraphQL introduces when compared to traditional API methods like REST. Unlike REST APIs, GraphQL APIs provide a standard endpoint for all data structure access and accepts formatted messages to return “parallel” responses containing only the desired data outlined in the initial request. The messages are standardized with JSON encoding, making the operation of this service
language-agnostic and extremely adaptable to even the most fringe use-cases. A GraphQL backend is typically accessed through a POST request directed at a single endpoint (e.g. /graphql or /api), which contains a JSON body that specifies the desired data for retrieval. This message, known as a query, responds with the desired data in the same format as it was requested.

Contrasting this with traditional REST APIs, it should be noted that:
1) GraphQL makes all data available on a single endpoint, and
2) Users can alter the specific data being requested by simply editing the JSON body of the POST request being sent by their browser.

Now that we’ve gone over the basics of GraphQL, let’s dive into how attackers can leverage some of its unique features for their own benefit, thwarting the efforts of developers.

GraphQL Vulnerabilities

The first way GraphQL presents a unique opportunity for attackers is in its numerous avenues for reconnaissance. Once a GraphQL endpoint is identified by an attacker (which is usually a trivial process), they can use various methods to identify the schema and organization characteristics, mapping out the potential contents of the backend data structure. For example, GraphQL contains a feature known as introspection, which is a dev tool that allows for a single request to reveal the entire scope of the backend data structure in JSON format. Although this feature is known to induce security concerns, it is enabled by default and many developers neglect to remedy this in production environments – allowing attackers to very quickly enumerate any objects of interest. GraphQL’s own documentation neglects to provide accurate methods to disable this feature, but a general workaround can be found in a guide by Kalil Stemmler of Apollo. However, even with this feature disabled, the accessibility of the JSON encoded requests allow attackers to edit legitimate requests in unwanted ways, accessing de-listed or otherwise inaccessible parts of the data structure through various parameter tampering methods. The latter method appears frequently in vulnerability submissions to bug bounty programs, leading to a form of Insecure Direct Object Reference (IDOR) vulnerabilities that can give attackers access to sensitive data from other users, being dubbed a “GraphQL IDOR” by Admir Dizdar of Brightsec.

While an attacker can already pose a serious threat after some simple investigation of a GraphQL host, knowing the unique infrastructure vulnerabilities around GraphQL implementations can make them considerably more dangerous. Even with introspection disabled, attackers can leverage debugging tools present in common GraphQL frameworks like Apollo (which is also used in HPE Aruba Networking’s NSP) to attempt to fuzz specific object names, foot-printing the backend schema manually. This process is automated by tools like @nikitastupin’s Clairvoyance, which enable the near-complete enumeration of Apollo GraphQL systems, even with introspection completely disabled. This, along with certain manipulations present in GET requests towards GraphQL endpoints, lead many sources to conclude that GraphQL schemas are incredibly easy to enumerate by advanced attackers, and should not be assumed to be secure in any public-facing implementation4.

If attackers decide to target GraphQL systems for more than just reconnaissance, the required countermeasures are also highly distinct when compared to their REST API equivalents. To illustrate, the first and most major concern with GraphQL attacks is the capability for attackers to trigger unrestricted resource consumption in backend hosts, with the OWASP API top 10 claiming that 69% of hosts are currently affected by these vulnerabilities. While many devs may respond to this concern with some form of rate-limiting, these measures must be fundamentally reconsidered when comparing GraphQL with REST implementations. As HTTP requests using GraphQL can hold many unique and individual queries, due to GraphQL’s ability to use aliases to reference the same object multiple times, standard rate-limiting techniques like spacing out requests are easily circumvented, unless more thorough measures are put into place. Many resources advise devs to use more logical rate-limiting measures like limits on query depth or implementing custom complexity scores to ensure that each request does not consume an unexpected amount of resources on the backend. Additionally, GraphQL targets can easily fall victim to CSRF vulnerabilities if CSRF tokens are not properly implemented on the GraphQL-enabled webapp.

Conclusion and Recommendations

So now that these most common and impactful vulnerabilities stemming from GraphQL have been identified – you may be asking yourself, how can I leverage my awareness of these vulnerabilities? Luckily, many of the remediations necessary to fortify your GraphQL deployment are as simple as configuration changes and infrastructure provisioning. To start, it is vital to ensure that features like introspection are disabled on any production deployments, but it is important to keep in mind that you will likely not keep your schema organization a secret for very long – if there is anything stored in your GraphQL database that you cannot have falling into attacker’s hands, reconsider how you are storing this data. In addition, it is crucial to have authentication and authorization occurring on a separate API layer from your GraphQL deployment, as to ensure that access to your data can be accounted for and monitored. Alongside proper authentication and authorization, making sure that users can only access their own data ensure that these security measures are delivered effectively – which can be done by implementing non-consecutive (or completely randomized) ID numbers for user information. Going along with earlier points, if an attacker can guess part of your GraphQL contents, they can likely also access it.

Furthermore, leveraging built-in features like query depth limits and operation limits will allow for logical rate-limiting, that also counters the unique DoS vulnerabilities introduced in GraphQL. Finally, in order to nip any potential CSRF vulnerabilities in the bud, ensure that CSRF tokens are enabled and only processed through HTTP POST requests (GET requests have also been known to be vulnerable to CSRF, even with adequate token implementation). While new GraphQL vulnerabilities are discovered and submitted every day, these configurations will secure your GraphQL deployment against many of the most common vulnerabilities and place your deployment far above those you might see in the wild.