Like any technology, operating GraphQL comes with security considerations to account for. Many of the security considerations stem from what makes GraphQL great - its flexibility. We’ve shipped several new features that will help you harden your GraphQL API so that you may continue to take advantage of GraphQL’s flexibility without sacrificing security.
Thanks to Stellate’s 100 global points of presence (POPs), you can now prevent queries attempting to exploit the most common GraphQL attack points from ever reaching your origin.
: number of directives that you can use in your GraphQL query. Well-crafted operations often contain a few
@includedirectives to fine-tune the selection, but at a certain threshold, they can be considered an attempt to simply stress the origin server.
Alias Limits: the number of aliases that you can use in your GraphQL operation. Aliases per se are not evil, but by allowing too many, an attacker can easily query huge chunks of your graph in a single request.
Request Size Limits: the maximum GraphQL request size. To make it easier to reason about we decided to limit on two simple parameters: for
POSTrequests we look at the body size. For
GETrequests we use the query component of the URI. Each of both is not allowed to exceed the defined limit. By setting this limit, memory exhaustion and denial-of-service attacks can be prevented. At the same time, it limits the selection of the graph to not query all at once.
Suggestion Masking: provides security when you have introspection disabled. “Did you mean” suggestions of GraphQL server implementations open up the potential to explore your schema by sending arbitrary (invalid) queries, and use the suggestions to piece-by-piece expose your schema information. Each of those valid fields can subsequently used to query data in a way you did not intend.
The security filters are configured in the Stellate dashboard and apply to every request. Visit our docs to learn more.
Persisted Operations Registry
Persisted Operations (POs) is a pattern in which a client sends a hashed GraphQL query to the GraphQL server, which is then looked up and translated to its query string, and only executed if found in the local registry. While POs are great for security, they make caching and observability difficult.
To bring caching and observability to POs, the Stellate cli and API now support sending your PO registry to Stellate. Stellate receives the persisted operation hashes, maintaining the desired security outcome without impeding performance and observability.
PO Query Response Caching: Stellate can analyze and cache query responses for hashed queries. In the case of a MISS or PASS, the query arrives at your origin unfurled. Optionally, we can forward the query to your origin in the original hashed shape
PO Observability: Stellate provides insights in the context of the raw GraphQL query. This affords POs the same insights as non-PO queries, such as the amount of usage and most recent usage.
Integrating Stellate into your PO workflow is as simple as running
stellate persisted-operations push. Head on over to our docs to learn more.
Rate Limiting General Availability
Stellate Rate Limiting marks the first time GraphQL engineers have been able to craft rate limiting strategies using native GraphQL constructs such as queries, mutations, and fields. Historically, rate limiting was limited to primitives such as IP and geo without the ability to craft rules around the query selection.
With Stellate Rate Limiting, we’re taking it a step further. We’re introducing support for custom typescript functions. Custom functions enable you to perform logic specific to your service such as defining a rule based on the contents of a JWT claim like the user's billing plan. Best of all - you can test your rules in dry run mode.
To learn more about rate limiting, visit our docs.
We want to hear what you’re up to - how are you trying to level-up with GraphQL and how we can help? Please reach out to firstname.lastname@example.org so we can connect, grow, and learn from each other.