Mitigate GraphQL Risks and Secure Your APIs with Prisma Cloud

GraphQL is a powerful, open source data query and manipulation language for APIs that has been getting a lot of attention because of its efficiency over traditional REST APIs. But, as with all technology, GraphQL has security risks that need to be addressed to confidently harness its power.

In this post, we’ll explain what GraphQL is and why it's gaining popularity. We’ll then take a closer look at common GraphQL security risks and outline how you can protect your GraphQL servers using Prisma Cloud’s Web App and API Security (WAAS) capabilities.

GraphQL Defined

GraphQL is a query language for APIs that was developed by Facebook in 2012. Because of its efficiency over traditional REST APIs, GraphQL is becoming increasingly popular with developers.

GraphQL vs. REST APIs

In many cases, when using traditional REST APIs to get the data you require, you'll need to send several requests to the API. While doing so, chances are high that you’ll fetch a lot of data you don't need from the server. With GraphQL, clients can specify exactly what data they need in one request, and receive it in the required format. As a result, fewer requests are sent to the API and only relevant data is fetched, which improves efficiency.

In addition to the technical aspects, GraphQL is gaining favor because of its ease of use and developer experience. With many open source tools, developers can quickly and easily build powerful, data-driven applications using GraphQL.

Securing GraphQL

As with any technology that handles user data, GraphQL servers contain valuable data that attackers want to access, so security is a big concern. You can protect your GraphQL servers using Prisma Cloud’s Web App and API Security (WAAS) capabilities. Let’s look at common attacks on GraphQL.

Information Disclosure Attacks

Introspection Queries

GraphQL introspection is a powerful feature that allows clients to discover information about the schemas in GraphQL, including the types of data that can be queried and the structure of those queries. While introspection can be a useful tool for developers, it can also be used by attackers.

An attacker can use it to discover the structure of a GraphQL API, and then use that information to craft queries and access sensitive information.

To protect against GraphQL introspection attacks, it's important to carefully control access to the introspection feature of a GraphQL API. Introspection can be disabled or restricted to only authorized users or specific IP addresses in cases where, for example, we require only internal clients to be able to perform introspection queries.

Organizations using Prisma Cloud WAAS can apply the following custom rule to detect GraphQL introspection queries.

Figure 1. Applying GraphQL introspection rule

Exposure of Information Through Errors

Aside from abusing the introspection feature, another technique could provide attackers with information about the schema structure.

When sending an invalid query to GraphQL, it will return an error to indicate the problem and often send a suggestion on how to make the query work, sometimes even suggesting a stack trace. The auto-suggestion feature is great for developers attempting to debug the error, but in production environments, attackers can abuse the suggestion by sending a series of queries with various arguments and fields. Attackers then analyze the responses to gradually build up a picture of the API's schema and understand how the data is organized and accessed. This issue becomes especially problematic when it’s not possible to disable auto-suggestions, as is the case in many GraphQL implementations.

The same abuse can occur with the introspection feature. If attackers successfully carry out this technique and gain information about the schema, they can launch more targeted attacks, such as exploiting weaknesses in the schema or data model to access sensitive information.

Prisma Cloud WAAS users could leverage the Custom Rules feature to apply the following rule to detect, and then block, these responses from the GraphQL server.

If your GraphQL returns the information in a non standard way, you could modify the rule accordingly.

resp.body contains /"errors".*?("stacktrace"|Did you mean|GRAPHQL_VALIDATION_FAILED)/

Exposure of Information Through Debug Mode

Some GraphQL implementations allow a debug mode in which debug information is attached to responses from the server. This kind of information could include data that should not be exposed to clients.

Prisma Cloud users employing WAAS could use the Custom Rules feature to apply the rule below to detect responses from the GraphQL server with attached debug information and block them.

resp.body contains /"extensions"\s*?:\s*?{/

Denial of Service Attacks

Unrestricted Query Depth

GraphQL flexibility allows clients to specify what kind of data they want to obtain, but this flexibility comes at a price, as attackers can create complex and nested queries that could consume significant amounts of resources to fulfill the request, leading to resource exhaustion, and potentially causing the server to become unavailable for legitimate users.

For example, consider a GraphQL server that defines a user object, where each object has a name, ID, and list of friends, which is an array of user objects. An attacker could craft a query that fetches a user's friends, their friends' friends, and so on, to exhaust the server.

To prevent attackers from exploiting this issue, some GraphQL implementations offer depth limitation mechanisms to mitigate this problem.

Prisma Cloud customers using WAAS could use the Custom Rules feature and apply the following rule for protection for queries with depth over 5. Note - customers should modify the number according to the maximum depth to allow.

lowercase(urlQueryDecode(req.body)) contains /(\{[^{}]*){5,}/ or lowercase(urlQueryDecode(req.query_params["query"])) contains /(\{[^{}]*){5,}/

Array Batching Attack

A GraphQL batching attack is a type of security vulnerability where an attacker sends multiple GraphQL queries as an array of JSON objects in a single HTTP request. By doing this, an attacker can execute a large number of queries in a single request, which can overload the GraphQL server, exhaust its resources, and potentially cause a denial-of-service (DoS) attack. This can be done by sending an array of queries in one request.

Prisma Cloud customers using WAAS could use the Custom Rules feature and apply the following rule to detect array batching requests.

lowercase(urlQueryDecode(req.body)) contains /^\[.*?\]$/ or

Classic Denial of Service

Like any web technology, GraphQL is vulnerable to denial of service attacks when overloaded with requests. DoS attacks are designed to overwhelm a server with traffic, making it difficult or impossible for legitimate users to access the server.

Prisma Cloud WAAS users are protected from this threat using the DOS protection feature that allows them to enforce a rate limit on IPs or sessions to protect against high-rate DoS attacks.

When Working with GraphQL

GraphQL offers a powerful architecture for building APIs that enable efficient data retrieval and manipulation. Its security risks, though, must be understood and mitigated. While we’ve covered some of the common risks in this blog post, OWASP delves into the less common risks and maintains current resources to keep you in the know.

Learn More About API Security with Prisma Cloud

With Prisma Cloud WAAS, you can secure your web applications and APIs to safely harness the power of APIs. Discover the Prisma Cloud advantage with a free trial or read this 2-page WAAS datasheet.

Mitigate GraphQL Risks and Secure Your APIs with Prisma Cloud