One Endpoint to Rule Them All: Securing GraphQL in Modern Network Management
A deep dive on GraphQL, HPE Aruba Networking Central’s new API framework
Introduction
Earlier this year, HPE Networking proudly announced a long-awaited upgrade to our online network management service, New HPE Aruba Networking Central – sometimes referred to as “New Central”. HPE Aruba Networking Central released as a distinct offering with a host of new features, including a brand-new UI, revamped management dashboards, an intuitive network organization system, and to top it off – a new API framework powered by GraphQL to seamlessly coordinate user actions with backend tasks.
As with any new release, this GraphQL implementation received immediate attention from HPE Threat Labs, since this relatively new API framework has now been selected to power many features in Central: from user identification all the way to device configuration and management. As the primary threat hunters for HPE Networking, thoroughly testing against new features is personal to us. We want all users of our platform to have the best API security possible, regardless of any particular framework and its vulnerabilities. To fully assess this big change, we realized that a comprehensive understanding of the GraphQL API framework first had to be achieved. Through months of research and testing, we were able to uncover the following about GraphQL API security and apply it to our testing against the HPE Aruba Networking Central.
The Changing Landscape of API Security
Many seasoned network administrators are familiar with traditional REST APIs, which is the most commonly used API framework on the web today. This style of API framework allows for a near endless amount of web-based API controls, distributed across various endpoints attached to the same domain, usually behind some sort of /api directory (i.e. /api/create or /api/delete).
Fig. 1: A simple diagram demonstrating REST API functions
Despite the ease of use this provides, REST APIs face the trade-off of creating a large, distributed attack surface for malicious actors to take advantage of. Most REST API endpoints contain unique requirements for HTTP request types (GET, PUT, PATCH, etc.), unique response codes for different endpoints, and distinct behaviors based off of supplementary HTTP information like User Agents. This causes a problem when network administrators then must adjust security controls to each endpoint, which either results in a large heap of manual work, or unique gaps in more comprehensive security restrictions.
Historically, the main ways developers have defended REST APIs have been through the following key measures, which each correspond to highly ranked vulnerabilities in the OWASP API top 10:
Though these practices seem straightforward, implementing and maintaining these rulesets along with comprehensive authentication and accounting can be an incredibly cumbersome task. Due to this, many people hoped to improve upon the REST API framework to deliver a more secure concept of using APIs on the web. Thus, GraphQL was introduced.
Fig. 2: A simple diagram demonstrating GraphQL API functions, to contrast REST APIs
GraphQL, in a nutshell
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’s new take on API interactions is proving to be difficult to secure, with many novel GraphQL vulnerabilities arising in recent times. 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?
Before getting into our findings, let’s break down what makes GraphQL different compared to traditional REST APIs. 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, triggers a response with the desired data in the same format as it was requested.
Contrasting this with traditional REST APIs, it should be noted that:
- GraphQL makes all data available on a single endpoint
- GraphQL endpoints typically only receive POST requests
- 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 Misconfigurations
In this section, I’ll break down some of the most common and most dangerous vulnerabilities in GraphQL deployments and compare these descriptions to what we were able to uncover during a security assessment against the new HPE Aruba Networking Central.
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, various methods can be used to identify the schema and organization characteristics, mapping out the potential contents of the backend data structure. Notably, 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 a known 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 in the backend DB. Even in production environments, this feature is often turned on for debugging or maintenance purposes. When searching for this weakness in Central, we were delighted to find that no regular or encoded introspection queries were interpreted by the system. This means that not only was introspection disabled, but a strict input filter had been put in place to prevent latent misconfigurations from being triggered by creatively constructed queries in the future. Additionally, when attempting to use advanced techniques like GraphQL GET request smuggling to trigger introspection responses, the application was not fooled by sending unexpected/malformed requests and caught any introspection payloads in the same way as before.
Even with introspection disabled, attackers can leverage other debugging features present in common GraphQL frameworks like Apollo to attempt to fuzz specific object names, foot-printing the backend schema manually. This process is automated by tools like @nikitastupin’s Clairvoyance, which enables the near-complete enumeration of Apollo GraphQL systems, even with introspection completely disabled. This tool relies on verbose error messages from Apollo GraphQL servers to be returned to clients by sending malformed requests. During testing, however, it was found that the New Central API responds to any malformed request not with suggestions or corrections, but rather a blank response indicating 0 results found by the query. Since this gives attackers nothing to go off of, they must keep guessing to ascertain any extra information about the backend database schema. To illustrate these differences, compare the following requests:
Fig. 3: A successful “getSiteHealth” request using valid parameters tied to the user
Fig. 4: A manipulated “getSiteHealth” request using spoofed parameters
These results were then confirmed following various attempts at running Clairvoyance with different wordlists, only to get erroneous results every time.
Moving away from schema-based reconnaissance, the simplicity of the GraphQL’s JSON queries can also 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. This can lead to a form of Insecure Direct Object Reference (IDOR) vulnerability that can give attackers access to sensitive data from other users, being dubbed a “GraphQL IDOR” by Admir Dizdar of Brightsec. When this vulnerability was tested for Central, it was abundantly clear that the engineers behind Central were aware of this form of abuse and had compensated for it thoroughly. Although the JSON used in GraphQL queries is not required to be strictly ordered, Central enforces an exact format for these queries – so even swapping the order of two JSON fields will suddenly result in a null response from the backend server (like the one illustrated in Fig. 2). Similarly, inputting incorrect or mismatched data to fuzz the logic of the backend service will result in identical null responses – giving indication that there is intermediary logic in place that processes the validity of queries, before they are even made visible to the internal GraphQL service.
Outside of attacks that directly affect the information stored and supplied by the GraphQL API, there are also latent GraphQL API behaviors that could lead to high-risk scenarios when effectively exploited by attackers. The most severe vulnerability of this kind is the potential for attackers to trigger unrestricted resource consumption in backend hosts, leading to Denial of Service (DoS) for other users. This kind of vulnerability is highlighted by the Escape GraphQL Security Report 2024, which claims that 69% of internet-connected hosts are currently vulnerable to a form of DoS vulnerability. While many developers may respond to this concern with some form of request-based rate limiting, these measures must be fundamentally reconsidered when comparing GraphQL with REST API 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 developers 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.
When testing for the previously mentioned DoS vulnerability, we were successful in identifying faulty logic in the aliasing features of Central GraphQL queries – showing that query depth was not strictly enforced on the backend GraphQL deployment. This faulty logic could be leveraged in more advanced attacks, like a Distributed DoS (DDoS) attack to potentially stop other Aruba Central customers from accessing their network configurations. Following our assessment, we put together our findings and presented them to the engineers maintaining the New HPE Aruba Networking Central – despite their low impact, we were happy to see that all relevant fixes were pushed to the production branch of the product within the same week they were reported.
Conclusion
Through this thorough research on GraphQL we were able to identify some potential gaps in our GraphQL deployment, but more often than not we were pleasantly surprised by our engineering team for being two steps ahead of us. Knowing that API security is an ongoing priority for the Central engineers gives us the peace of mind to recommend HPE Aruba Networking Central as the future of secure network management. Through this excercise, we also learned the critical importance of understanding API security and hope we have shared these same lessons with our readers.
Moreover, this assessment allowed us to take a close look at how GraphQL APIs are secured, and what differentiates them from their REST counterparts. Through this assessment, it should be clear for network admins and blue-teamers alike that a secure API front, regardless of API framework, contains:
- Robust Authentication and Authorization controls
- Comprehensive understanding of how different HTTP request types are used
- Rate-limiting tailored to the type of API used
- Distinct boundaries between acceptable and unacceptable use
By practically demonstrating the effects of these API security enhancements, users can rest assured that network management in New HPE Aruba Networking Central is defended thoroughly by our attentive development team. Moreover, we hope that users will have the peace of mind knowing that with every new feature or change in infrastructure, HPE Threat Labs will be there to make sure security is not just implemented in theory, but demonstrated through active testing.