All the knobs - GraphQL Guardrails Cover.png

large_All the knobs - GraphQL Guardrails Cover.png

medium_All the knobs - GraphQL Guardrails Cover.png

small_All the knobs - GraphQL Guardrails Cover.png

thumbnail_All the knobs - GraphQL Guardrails Cover.png

GraphQL DoS (Denial of Service) attacks target GraphQL parsers, GraphQL resolvers, and the underlying DBs in a single API call.
It is possible to protect your server from these attacks with a set of guardrails and GraphQL usage-based rate-limiting.

So far, we've covered [GraphQL Security Awareness](https://inigo.io/blog/how-secure-is-your-graph-ql-server) and have understood that [No, You Don't Need to Disable Introspection](https://inigo.io/blog/you-dont-need-to-disable-introspection). Now, let's take a look at the different security knobs needed to guardrail a healthy GraphQL request.

## It’s All About DoS
GraphQL DoS (Denial of Service) attacks target GraphQL parsers, GraphQL resolvers, and the underlying DBs in a single API call. They include batching, nested, heavy and complex, N+1, and circular attacks which can bring your server down and affect server availability.

Fortunately, it is possible to protect your server from these attacks with the help of a set of guardrails and GraphQL usage-based rate-limiting.


![All the knobs - GraphQL Attack Surfaces.png](/uploads/All_the_knobs_Graph_QL_Attack_Surfaces_f67bc38145.png)

## How to Protect - Inbound
Below is a list of security knobs that any GraphQL adopter should implement. Ideally, these configurations are set together with per-role access control to limit attacks.

![All The knobs - GraphQL Security - Inbound.png](/uploads/All_The_knobs_Graph_QL_Security_Inbound_8f9a279d13.png)

#### Limit Directives
As one of our favorite security knobs, limit directives help to guard against parser overload attacks.
Overloading the parser with hundreds of directives can result in the server crashing without the request reaching the resolvers. (Credits: [@unixhopper](https://twitter.com/unixhopper))

![GraphQL Limit Directives for Parser Attack.png](/uploads/Graph_QL_Limit_Directives_for_Parser_Attack_e4ced2233a.png)

#### Limit Depth
Helps to guard against nested and N+1 attacks that overload resolvers and DB with complexity and loops.

![GraphQL Limit Depth for Nested Attack.png](/uploads/Graph_QL_Limit_Depth_for_Nested_Attack_797afe467d.png)

#### Limit Height
Helps to guard against alias attacks like overloading DB access for the same field or type.

![GraphQL Limit Height for Alias Attack.png](/uploads/Graph_QL_Limit_Height_for_Alias_Attack_e8e02c300f.png)

#### Limit Root Fields
Helps to guard against batch attacks like password guessing and OTA bypassing.

![GraphQL Limit Root Fields for Batch Attack.png](/uploads/Graph_QL_Limit_Root_Fields_for_Batch_Attack_995f0888e4.png)

#### Limit Request Size
Offers fallback protection for complex requests by limiting the size of the request.

#### Force Operation Name [Bonus]
Make sense of your analytics and telemetry. While the uniqueness of the name can’t be enforced, having a name makes it much easier to gain context of the call and differentiate it from other calls when reviewing API usage.

![GraphQL Improve visibility and force name.png](/uploads/Graph_QL_Improve_visibility_and_force_name_5810a05e28.png)

## How to Protect - Outbound
#### Demand-based Rate Limiting (aka Usage-based)
We found that the most robust way to think about GraphQL Rate Limiting is to look at the server’s consumption and real usage. Counting each query’s returned objects against a timeframe limit (e.g. 1,000 credits per minute).

Credits can be configured in a few ways: 
- Statically Configured - All objects are counted as 1 credit.
- Manually Configured - Since not all fields are equal, some may take more time to retrieve than others  (e.g. computed fields). In this configuration, developers can manually assign different credit weights to different types and fields.
- Dynamically Configured - Credits are calculated based on the GraphQL tracing and server time to respond.

This approach works best with granular access control, where heavy-usage roles have a larger allowance as opposed to other roles or even unauthenticated calls.

#### Cost Analysis-based Rate Limiting (aka Predictive-based)
Alternatively, if you are using GraphQL-JS, there are a few libraries that might help to predict the complexity of a query:
- [GraphQL Validation Complexity](https://github.com/4Catalyzer/graphql-validation-complexity) (GraphQL-js only)
- [GraphQL Query Cost Analysis](https://github.com/pa-bru/graphql-cost-analysis) (GraphQL-js only)

#### Limit Response Size
If all else fails, limit the size of the response.

## What’s Next
Ready to defend against GraphQL server attacks? Inigo can help! [Connect with us today.](https://inigo.io/contact-us)

Inigo offers a platform-agnostic approach to remove barriers and open possibilities for any open-source or commercial GraphQL server.

Be sure to subscribe to our newsletter to get notified of our next posts, where we dive deeper into GraphQL-specific attacks.




All The Knobs - GraphQL Security Guardrails 

Granular Introspection Access Control Cover

large_Granular Introspection Access Control.png

medium_Granular Introspection Access Control.png

small_Granular Introspection Access Control.png

thumbnail_Granular Introspection Access Control.png

Granular Introspection Access Control Cover.png

A closer look at how granular access control can help protect from weaknesses around Introspection, field suggestions, and field fuzzing.

As discussed in our last post, [How Secure is Your GraphQL Server?](https://inigo.io/blog/how-secure-is-your-graph-ql-server), inconsistencies in GraphQL implementations are common among the different GraphQL offerings.

Let’s take a closer look at how granular access control can help protect from weaknesses around schema fetching.

## Schema Fetching
Introspection, field suggestions, and field fuzzing play a significant role in equipping abusers with information on their target’s functionality by allowing insecure data mapping and sensitive information disclosure.

### Introspection
For many developers, the common practice is to disable Introspection – the first topic you come across when researching methods to secure your GraphQL. As a result, the discoverability nature of the feature will be lost. Those who choose to keep Introspection open are left with an “all-or-nothing” dilemma, exposing sections of the schema to users who don’t have access.

### Field Suggestions
The vast majority of GraphQL implementations don’t offer developers control for field suggestions, which allows abusers to quickly map the schema using field fuzzing even when Introspection is disabled. Supplying incorrect fields will trigger GraphQL to disclose fields with similar names.

![Granular Introspection Access Control Response.png](/uploads/Granular_Introspection_Access_Control_Response_e034ffb94b.png)

## How to Protect
If you are looking for an approach that can both limit the visibility of the schema and allow your users to explore it, consider role-based granular access control.

Inigo allows developers to configure edge-based access control, resulting in a different Introspection experience per role while still maintaining one schema. Based on their role, users will only be exposed to the types and fields they have access to. 

### Benefits
- Limited visibility
- Reduce users confusion
- Keep abusers in the dark

### Starwars GraphQL example:

![Granular Introspection Access Control.png](/uploads/Granular_Introspection_Access_Control_fef37268cd.png)

With Inigo’s granular Introspection access control, field suggestions are disabled while only approved fields are visible via Introspection per role – regardless of the specific GraphQL server implementation. As a result, multiple variations of Schema Fetching are prevented, allowing you to feel more confident in the security of your GraphQL server. 

![Field Suggestions With Granular Introspection Access Control](/uploads/Field_Suggestions_With_Granular_Introspection_Access_Control_2dd0ef5fea.png)

## What’s Next
Ready to defend against GraphQL server attacks? Inigo can help! [Connect with us today.](https://inigo.io/contact-us)

Inigo offers a platform-agnostic approach to remove barriers and open possibilities for any open-source or commercial GraphQL server.

Be sure to subscribe to our newsletter to get notified of our next posts, where we dive deeper into GraphQL-specific attacks.


No, You Don’t Need to Disable Introspection

large_ post_1-1.png

medium_ post_1-1.png

small_ post_1-1.png

thumbnail_ post_1-1.png

 post_1-1.png

Like any new technology, security awareness is often lagging behind adoption. For this reason, GraphQL attack surfaces are bound to unfold for many of its users.

Like any new technology, security awareness is often lagging behind adoption. For this reason, GraphQL attack surfaces are bound to unfold for many of its users. These attacks range from Parser Attacks and Resolver Attacks to Data Manipulation and even Data Leaks. 

GraphQL attack surfaces are quite unique. An attacker can target one or more surfaces with one API call that would easily pass through any standard API gateway. Here we’ll discuss the implications of an unsecured GraphQL server and who could be at risk, so keep reading to learn more. 

## GraphQL Security Awareness

To get a better understanding of GraphQL security awareness amongst users, we decided to conduct a short survey. Our Reddit GraphQL survey titled ”How Do You Think About GraphQL Security?” had an interesting but not surprising spread of replies.

![GraphQL Security Awareness Survey.png](/uploads/Graph_QL_Security_Awareness_Survey_b8876fbf4d.png)

During one-on-one interviews, participants who were already aware of GraphQL’s attack surfaces reported that this knowledge came from a negative experience: their own servers had been compromised. 

## Who is Impacted

Most of us.

While GraphQL builds are [available](https://graphql.org/code/) in any programming language you could ask for, they are not all built the same nor do they have the same supportive community size or security awareness. Just this week, a circular-fragment attack was demonstrated to crash [Aago](https://github.com/ohler55/agoo)’s Ruby-Server implementation on GitHub and was reported as [CVE](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30288). 

[Nick Aleks](https://twitter.com/Nick_Aleks) and [Dolev Farhi](https://twitter.com/dftrace) did a fantastic job detecting and documenting vulnerabilities across multiple GraphQL:

![GraphQL servers implementation.png](/uploads/Graph_QL_servers_implementation_859d62f5d0.png)

(Source: [GitHub](https://github.com/nicholasaleks/graphql-threat-matrix))

Large resource-heavy engineering teams usually end up developing in-house tooling and building blocks to customize and tighten their GraphQL deployments. This approach is not always easy to maintain and is often prone to errors. [HackerOne](https://hackerone.com/hacktivity?querystring=graphql) is another excellent source that further explains how GraphQL attacks impacted different companies. 

So, how secure is your GraphQL server? Unfortunately, it’s not so much a question of if a GraphQL attack will happen to you, but when.

## What’s Next

Ready to defend against GraphQL server attacks? Inigo can help! [Connect with us today.](https://inigo.io/contact-us) 

Inigo offers a platform-agnostic approach to remove barriers and open possibilities for any open-source or commercial GraphQL server.

Be sure to subscribe to our newsletter to get notified of our next posts, where we dive deeper into GraphQL-specific attacks.

Platform

Developers

Resources

Pricing

All The Knobs - GraphQL Security Guardrails

More posts

All The Knobs - GraphQL Security Guardrails

No, You Don’t Need to Disable Introspection

How Secure is Your GraphQL Server?

Join our Newsletter

Inigo

GQL Platform

Developers

Resources