large_Alias-based Query Batching.png

medium_Alias-based Query Batching.png

small_Alias-based Query Batching.png

thumbnail_Alias-based Query Batching.png

Alias-based Query Batching.png

GraphQL isn’t immune to vulnerabilities, it may suffer from them just like any other API technologies such as REST, SOAP, gRPC, or others, but there are some unique and interesting possibilities that open up to hackers when GraphQL is present on the target they are interested in compromising.

GraphQL isn’t immune to vulnerabilities, it may suffer from them just like any other API technologies such as REST, SOAP, gRPC, or others, but there are some unique and interesting possibilities that open up to hackers when GraphQL is present on the target they are interested in compromising.

Vulnerability classes such as Injection, Denial of Service, Forgery, Lack of Resource & Rate Limiting as well as others, can all apply to GraphQL APIs. However, what’s interesting in GraphQL is the new ways it allows threat actors to optimize certain attacks, specifically those that fall under the category of denial of service and defeating authentication mechanisms.

![Secured GraphQL.png](/uploads/Secured_Graph_QL_f702a31dbb.png)

Aliases in GraphQL allow clients to rename response keys of fields and use the same query operation more than once. Let’s first see what happens when a client asks for simple information such as the ID of users:
```
query {
  users {
    id
  }
}
```
And the response:
```
{
  "data": {
    "users": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
If a client attempts to fetch the same information more than once this way:
```
query {
  users {
    id
  }
  users {
    id
  }
}
```
Then the response returned by the GraphQL server will only return a single users key in the response:
```
{
  "data": {
    "users": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
The JSON structure we get back from the GraphQL server returns a single key, so the response of two operations is consolidated to a single response key.

Aliases in GraphQL allow you to rename the operation name (and hence the JSON key in the response). Aliases can be configured by prefixing the field of interest with some named alias:
```
query {
  nameOne: users {
    id
  }
  nametwo: users {
    id
  }
}
```
Which results in the GraphQL server returning the following response:
```
{
  "data": {
    "nameOne": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ],
    "nametwo": [
      {
        "id": "1"
      },
      {
        "id": "2"
      }
    ]
  }
}
```
This allows you to run multiple queries and rename their response key, which allows you to get separate responses. 

GraphQL APIs just like any other API can perform sensitive actions such as:
1. User login
2. User password resets
3. User signup
4. Token verification
5. Code verification

This list is just the tip of the iceberg, there could be more options, but you get the point. 

Back to aliases - aliases allow you to “stuff” multiple operations in a single HTTP request. Does that ring any of your security bells? It should, because traditional security controls could struggle identifying malicious behavior if they rely on certain characteristics that are more relevant to non-GraphQL based APIs. For example:

- HTTP Method (POST/GET)
- API Route (e,g, /v1/login)
- Number of clients requests made (e.g. 100 per minute)
- The returned HTTP code

Looking at all of these as indicators of potential compromise attempt makes sense in the context of security: If a client makes a POST request to the /v1/login endpoint 100 times in 5 seconds and the response code is 401 Unauthorized, maybe this client is attempting to brute force accounts on your application. These heuristics make sense in non-GraphQL APIs. In GraphQL, the heuristics are a little different.

In GraphQL, the client intention is not expressed by the HTTP verb, route, or the returned code (in many cases) but by the query payload. Determining how the GraphQL server handled the query is expressed in the response versus any HTTP headers.

So, if you have a login GraphQL query that takes in an email and password, it would look like the following:
```
query {
  login(email:"user123@example.com", password:"abc") {
    token
  }
}
```
With aliases, we can now perform multiple login attempts and send those over a single HTTP request:
```
query {
 attemptOne: login(email:"user123@example.com", password:"abc") {
    token
 }
 attemptTwo: login(email:"user123@example.com", password:"def") {
    token
 }
 attemptThree: login(email:"user123@example.com", password:"geh") {
    token
 }
}
```
This query structure could circumvent security controls that perform rate limiting that bases its heuristics on the volume of client requests combined with the HTTP method and API route being used. As GraphQL adopters, it’s important to find a solution that can protect your APIs and identify malicious behavior more tailored to GraphQL APIs.

Aliases can be used to batch any query (or mutation) but not both at the same time. In the next post, we will cover another method of query batching that allows mixing these two types together.


Defeating Controls with Alias-based Query Batching

large_Public GraphQL Vulnerability Header.png

medium_Public GraphQL Vulnerability Header.png

small_Public GraphQL Vulnerability Header.png

thumbnail_Public GraphQL Vulnerability Header.png

Public GraphQL Vulnerability Header.png

We spent a few days examining data from two main sources: The CVE database by MITRE and the HackerOne Hacktivity portal to see what we can learn from analyzing GraphQL vulnerability data.

One way to learn about GraphQL security is by analyzing public information related to vulnerabilities impacting GraphQL components such as GraphQL clients (like Relay) or GraphQL servers (like Apollo, Graphene, Ariadne, and even products like GitLab Enterprise, Magento, etc). We spent a few days examining data from two main sources: The CVE database by MITRE and the HackerOne Hacktivity portal to see what we can learn from analyzing vulnerability data.

![Public GraphQL Vulnerability .png](/uploads/Public_Graph_QL_Vulnerability_78fe425985.png)

## GraphQL Vulnerability Data Analysis - MITRE CVE Database
The [MITRE CVE](https://cve.mitre.org/) database is the source of truth for CVEs. Before diving into the dataset, it’s important to highlight a few important things about the database:

1. Not all vulnerabilities are reported.
2. Not all vulnerabilities receive a CVE identifier.
3. Some vulnerabilities are reported but never get a CVE identifier assigned.

The reason this is important to highlight is, while the CVE database is a good data sample, it is not a comprehensive list of vulnerabilities. 

Generally speaking, vulnerabilities get a CVE identifier when either the vendor of the software impacted by the vulnerability or the researcher who found the flaw engages MITRE and files a CVE request. Some software vendors are authorized to issue their own software a CVE identifier, these vendors are acting as a CNA (CVE Numbering Authority) and you can find the list of CNA partners [here](https://www.cve.org/PartnerInformation/ListofPartners), on this list you can find vendors such as GitLab, Adobe, GitHub, and more.

To get an idea of the GraphQL vulnerability dataset, we used the MITRE CVE database search option, where you can perform a free-text search. Here is what the search-term “GraphQL” brings up:

![Public GraphQL Vulnerability CVE list.png](/uploads/Public_Graph_QL_Vulnerability_CVE_list_a4d1d63633.png)

Having access to this dataset, a few questions came up:

1. How many vulnerabilities are there with CVEs?
2. What are the most common vulnerability classes?
3. When was the first vulnerability tracked?
4. Which GraphQL component has the most CVEs?

### How many vulnerabilities are there with CVEs?
The search yielded a [few dozen](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=graphql) (45) CVEs related to GraphQL components, such as GraphQL servers, GraphQL client libraries, and so on. 

### What are the most common GraphQL vulnerability classes?
Authorization (54%) and DoS-based (16%) vulnerabilities were the most popular vulnerability classes, as shown in the pie chart below.

![Public GraphQL Vulnerability CVE.png](/uploads/Public_Graph_QL_Vulnerability_CVE_4fb711cdb8.png)

### When was the first vulnerability tracked?
Purely based on the CVE identifier strings, the oldest entry is from 2019 (CVE-2019-1000011) this is likely not the first ever vulnerability found in software with GraphQL, but it’s the oldest found in MITRE’s database.

### Which GraphQL software has the most CVEs?
This data is likely skewed by the popularity of the component itself, and is not indicative of how hardened a component is or is not, but nevertheless it is interesting data to analyze:

![Public GraphQL Vulnerability CVE By Component.png](/uploads/Public_Graph_QL_Vulnerability_CVE_By_Component_6820b932c8.png)

## GraphQL Vulnerability Data Analysis -  HackerOne
The [HackerOne](https://hackerone.com/) vulnerability database is a great resource to learn about the types of vulnerabilities researchers report on and get credited for. We performed a search against the public reports on HackerOne to see what types of vulnerabilities have been reported so far.

Since 2018, 74 vulnerabilities have been reported to various companies and bounties ranging anywhere from $250 to north of $20,000 were granted. Most vulnerabilities were in the category of Authorization flaws (87%), followed by DoS (7%) and others (5%)

![Public GraphQL Vulnerability Hacker One.png](/uploads/Public_Graph_QL_Vulnerability_Hacker_One_b985cdcb99.png)

Security researchers participating in bug bounty programs are often motivated by money, and authorization-related vulnerabilities very often result in data leakages and impact to personal identifiable information (PII) - these vulnerabilities are considered to be the most critical to companies and the reward for finding such vulnerabilities is, as such, very incentivizing - so it comes as no surprise that most ethical hackers will test for authorization flaws before anything else.

One important fact about Bug Bounty programs is that testing for Denial of Service-based vulnerabilities is more often than not disallowed (and many times their bounties are also comparatively low where it is allowed), this is reflected in the chart by the limited number of reported DoS vulnerabilities.

GraphQL continues to be interesting both from an offensive as well as a defensive standpoint. Inigo’s GraphQL Security and Management solution helps address Authorization, Denial of Service, as well as other classes of vulnerabilities in GraphQL APIs. 



Analysis of Public GraphQL Vulnerability Reports

Defending GraphQL APIs Challenging to Security Engineers.png

large_Defending GraphQL APIs Challenging to Security Engineers.png

medium_Defending GraphQL APIs Challenging to Security Engineers.png

small_Defending GraphQL APIs Challenging to Security Engineers.png

thumbnail_Defending GraphQL APIs Challenging to Security Engineers.png

It’s not enough to know how GraphQL works and how it can be attacked, what also matters a lot is whether security professionals have the necessary tools to identify suspicious queries, exploitation attempts, and solutions to protect against GraphQL-tailored attacks.

While GraphQL has been around for at least seven years since the first reference implementation [graphql-js](https://github.com/graphql/graphql-js) was released to the public in July 2015, many security professionals are not yet caught up with it. It’s not enough to know how GraphQL works and how it can be attacked, what also matters a lot is whether security professionals have the necessary tools to identify suspicious queries, exploitation attempts, and solutions to protect against GraphQL-tailored attacks.

Whether you have a Web Application Firewall (Cloudflare, Modsecurity, or other) monitoring your application for security events, or you’ve built an in-house monitoring solution based on standard access logs to detect suspicious behavior in web applications, you have probably developed some dependency on key indicators such as:

- HTTP methods (verbs)
- HTTP response status codes
- Sensitive API Routes
- API parameters

These indicators are helpful when you want to monitor for specific events, such as:

1. Clients hammering your registration endpoint
2. Clients attempting to login unsuccessfully multiple times
3. Clients attempting to perform account enumeration
4. Clients tampering with parameters of interest

Monitoring for such events in REST APIs is pretty trivial and requires a few things to be in place: it requires the protected application to follow [RFC2616](https://www.rfc-editor.org/rfc/rfc2616.html) when it comes to the returned HTTP status codes so the signals make sense to clients as well as the security engineering team, and it requires the security team to have a pretty good idea (and an inventory) of their APIs.

Traditional monitoring systems use HTTP components for monitoring. Here is an example of a pseudo-monitoring rule that could be beneficial to the security team in particular:

```
alert if (http.method=GET and response.status_code=403 and http.uri=”/v1/user/<id>/profile”) 
```

This example rule relies on the HTTP method (GET), a response code (403 Forbidden) and a specific route (/v1/user/id/profile), which will mostly be available in the case of REST APIs, but what about GraphQL?

![Inigo Observeability.png](/uploads/Inigo_Observeability_4a6f09d1de.png)

GraphQL uses a single GraphQL route (/graphql is pretty common). The reason routes don’t matter in GraphQL APIs is because client intentions are all based on the query payload. While it’s true GET and POST are in use in GraphQL APIs, it does not reflect what the client is ultimately trying to do, this is all derived from the query.

Going back to the case of monitoring APIs for security events, this design of GraphQL renders traditional security monitoring approaches pretty useless. Monitoring rules as shown above will no longer work, and different tools will be required to achieve the objective.

Not only is there an issue with the single route, GraphQL APIs don’t depend on normal HTTP status codes. It’s often the case that a GraphQL API will return a 200 OK to any query, while any errors will be reflected by the response payload coming back from the server using a dedicated **errors** JSON key with the error message relevant to what went wrong.

For instance, take a look at the example query below that allows a user to fetch their own user details by passing a numerical user ID:
```
query {
 user(id: 1000) {
 email
 name
 address
 }
}
```

If the calling client has authorization to view user ID 1000 and that ID exists, then such query would result in a response such as:
```
{
 "data": {
 "user": [
 {
 "email": "test@example.com",
 "name": "test user",
 "address": "123 Hollywood Blvd",
 }
 ]
 }
}
```

If the calling client does not have the right authorization level, a GraphQL response might look like the following:
```
{
 "errors": [
 "message": “You are not authorized to view this user.”
 ]
}
```

If the user ID does not exist on the system, a GraphQL response might look like the following:
```
{
 "errors": [
 "message": “User with ID 1000 does not exist”
 ]
}
```

The HTTP code to all three conditions could be a consistent 200 OK from the GraphQL server, which is why GraphQL is more challenging to monitor than traditional REST APIs. If your monitoring solutions are based on standard HTTP access logs, be prepared to see a lot of log lines that look like the following:

```
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
1.2.3.4 - - [02/Aug/2022:18:27:46 +0000] "POST /graphql HTTP/1.1" 200 - "-"
"curl/7.43.0" - 539
```

You can’t do a whole lot with this. For monitoring security events, you will need a view into the query payload, as well as the response payload, and a solution that can contextualize these events for you. To make matters worse, GraphQL allows batching multiple queries into a single HTTP request, therefore allowing threat actors to hide multiple actions in a single HTTP packet:

```
query {
 alias1000: user(id: 1000) {
 email
 name
 address
 }
 alias1001: user(id: 1001) {
 email
 name
 address
 }
 alias1002: user(id: 1002) {
 email
 name
 address
 }
}
```

When such a query is made, you will only see a single incoming HTTP request, despite the fact that 3 queries were made. 

If you thought it stops here, we’ve got some news for you: it is also possible to batch queries using an array against some GraphQL servers that support it, like so:

```
import requests

queries = [
 {
 "query":"query { user(id: 1000) { email name address }}",
 "query":"query { user(id: 1001) { email name address }}",
 "query":"query { user(id: 1002) { email name address }}"
 }
]

r = requests.post('http://test.inigo.local/graphql', json=queries)

print(r.json())
```

Inigo can help provide you with an observability layer tailored to GraphQL that handles these cases too.

What Makes Defending GraphQL APIs Challenging to Security Engineers

How Threat Actors Fingerprint your GraphQL APIs.png

large_How Threat Actors Fingerprint your GraphQL APIs.png

medium_How Threat Actors Fingerprint your GraphQL APIs.png

small_How Threat Actors Fingerprint your GraphQL APIs.png

thumbnail_How Threat Actors Fingerprint your GraphQL APIs.png

You’ve identified a GraphQL server, now what? Well, the next step in the process is to learn all you can about the specific server.

In previous blog posts, we discussed what’s involved in the process of [detecting GraphQL servers](https://inigo.io/blog/how_threat_actors_detect_your_graphql_apis). Threat actors don’t stop there, the identification of a target is only the initial step in the process of achieving the greater goal of compromising a GraphQL API target. 

You’ve identified a GraphQL server, now what? Well, the next step in the process is to learn all you can about the specific server. You may be asking yourself, aren’t all GraphQL servers the same; they just provide an API layer to some application? While this is true, the first thing you should know is that there are **many** GraphQL server implementations, not all of them are mature, and not all of them are well maintained.

Let’s explore some of the GraphQL servers that are out there today. A good source for this is the [https://graphql.org/code](https://graphql.org/code) website, which lists client libraries, servers, tools as well services by the language they were written in. For this post, we’re going to focus only on server implementations. Below chart illustrates the number of GraphQL server implementations available today by language. You can find the detailed table at the bottom of this post.

![GraphQL Servers Breakdown.png](/uploads/Graph_QL_Servers_Breakdown_fd16991ddd.png)

As you can see, there are many different server implementations. Most notable are PHP (22.8%) Golang (12.3%) JavaScript (10.5%) Java (8.8%) and Python (7%).

Why is this important? When threat actors target an application or server, they need to gather a few key data points to increase their chances of successfully breaking in:

1. What platform is running?
2. Is the source code available?
3. What version is it on?
4. Are there any known vulnerabilities for it?
5. Are there any available exploits for the vulnerabilities?
6. What security features are built into it?
7. Are there any insecure settings shipped by default?

To be able to know the answer to these questions, you first need to fingerprint the target. But how do you fingerprint an API? Since GraphQL is just an API layer, you may be asking yourself: how would someone know what GraphQL implementation it is if they should all conform with the specification and return the same predictable response structure? Well, if you craft a careful enough payload that the server does not expect, all it will take is a small and subtle difference in the response to distinguish one server from another. Let’s explore what this looks like.

![GraphQL Server Fingerprint.png](/uploads/Graph_QL_Server_Fingerprint_3a6d01008b.png)

GraphQL supports three operation types: query, mutation and subscription as described in section 2.3 Operations in the [GraphQL specification](https://spec.graphql.org/October2021/#sec-Language.Operations). What would happen if an operation that doesn’t exist is provided, and what would the server respond with? Let’s find out:

```
queryyy { # notice the typo
   __typename
}
```

Using curl, we will send this malformed query to an Apollo-based GraphQL server


```
$ curl -s -X POST http://apollo.example.local -H "Content-Type: application/json" -d '{"query":"queryyy { __typename }"}' | jq

{
  "errors": [
    {
      "message": "Syntax Error: Unexpected Name \"queryyy\".",
      "extensions": {
        "code": "GRAPHQL_PARSE_FAILED"
      }
    }
  ]
}
```

So, we have an errors key with a message of **Syntax Error: Unexpected Name \"queryyy\"**. Now, let’s do the same against a Graphene-based GraphQL server, a Python-based implementation.

```
$ curl -s -X POST http://graphene.example.local -H "Content-Type: application/json" -d '{"query":"queryyy { __typename }"}' | jq

{
  "errors": [
    {
      "message": "Syntax Error GraphQL (1:1) Unexpected Name \"queryyy\"\n\n1: queryyy { __typename }\n   ^\n",
      "locations": [
        {
          "line": 1,
          "column": 1
        }
      ]
    }
  ]
}
```

Now we see that the error message is a little different. For example, instead of **Syntax Error** we now get **Syntax Error GraphQL** in the error message. This is an obvious difference that can help us pinpoint the implementation. 

Tools that perform GraphQL fingerprinting surfaced over the years, such as [Graphw00f](https://github.com/dolevf/graphw00f) that make use of these subtle differences to arm ethical hackers with the necessary knowledge and give them the ability to perform more educated guesses during penetration tests.

We mentioned earlier that some implementations are more mature than others, and offer protections that others don’t. In future posts, we will cover various vulnerabilities of different implementations. Whether you are using a popular GraphQL server implementation, or completely wrote your own custom implementation, Inigo abstracts your GraphQL API layer and provides security protections so you don’t need to worry about securing your GraphQL server, we do that for you.  

## List of GraphQL server implementations available as of this writing


| #  | Implementation                       | Language   | URL                                                           |
| -- | ------------------------------------ | ---------- | ------------------------------------------------------------- |
| 1  | graphql-js                           | JavaScript | https://graphql.org/graphql-js/                               |
| 2  | apollo                               | JavaScript | https://github.com/apollographql/apollo-server                |
| 3  | graphql-yoga                         | JavaScript | https://github.com/dotansimha/graphql-yoga                    |
| 4  | express-graphql                      | JavaScript | https://github.com/graphql/express-graphql                    |
| 5  | mercurius                            | JavaScript | https://github.com/mercurius-js/mercurius                     |
| 6  | graphql-helix                        | JavaScript | https://github.com/contra/graphql-helix                       |
| 7  | graphql-go                           | Golang     | https://github.com/graphql-go/graphql                         |
| 8  | gqlgen                               | Golang     | https://github.com/99designs/gqlgen                           |
| 9  | graphql-go (graph-gophers)           | Golang     | https://github.com/graph-gophers/graphql-go                   |
| 10 | thunder                              | Golang     | https://github.com/samsarahq/thunder                          |
| 11 | graphql-relay-go                     | Golang     | https://github.com/graphql-go/relay                           |
| 12 | jaal                                 | Golang     | https://github.com/appointy/jaal                              |
| 13 | eggql                                | Golang     | https://github.com/andrewwphillips/eggql                      |
| 14 | api-platform                         | PHP        | https://api-platform.com/                                     |
| 15 | graphql-php                          | PHP        | https://github.com/webonyx/graphql-php                        |
| 16 | WPGraphQL                            | PHP        | https://github.com/wp-graphql/wp-graphql                      |
| 17 | Lighthouse                           | PHP        | https://github.com/nuwave/lighthouse                          |
| 18 | Siler                                | PHP        | https://github.com/leocavalcante/siler                        |
| 19 | GraphQLBundle                        | PHP        | https://github.com/overblog/GraphQLBundle                     |
| 20 | GraphQLite                           | PHP        | https://github.com/thecodingmachine/graphqlite                |
| 21 | Ralit                                | PHP        | https://github.com/railt/railt                                |
| 22 | graphql-relay-php                    | PHP        | https://github.com/ivome/graphql-relay-php                    |
| 23 | GraphQL by PoP                       | PHP        | https://github.com/leoloso/PoP                                |
| 24 | GraphQL API for WordPress            | PHP        | https://github.com/leoloso/PoP                                |
| 25 | GraPHPinator                         | PHP        | https://github.com/infinityloop-dev/graphpinator              |
| 26 | serge                                | PHP        | https://github.com/kepawni/serge                              |
| 27 | graphql-java                         | Java       | https://github.com/graphql-java/graphql-java                  |
| 28 | Domain Graph Service (DGS) Framework | Java       | https://github.com/netflix/dgs-framework                      |
| 29 | graphql-kotlin                       | Java       | https://github.com/ExpediaGroup/graphql-kotlin                |
| 30 | GraphQL Spring Boot                  | Java       | https://github.com/graphql-java-kickstart/graphql-spring-boot |
| 31 | KGraphQL                             | Java       | https://github.com/aPureBase/KGraphQL                         |
| 32 | graphql-dotnet                       | C# / .NET  | https://github.com/graphql-dotnet/graphql-dotnet              |
| 33 | Hot Chocolate                        | C# / .NET  | https://github.com/ChilliCream/hotchocolate                   |
| 34 | NGraphQL                             | C# / .NET  | https://github.com/rivantsov/ngraphql                         |
| 35 | Graphene                             | Python     | https://github.com/graphql-python/graphene                    |
| 36 | Strawberry                           | Python     | https://github.com/strawberry-graphql/strawberry              |
| 37 | Ariadne                              | Python     | https://github.com/mirumee/ariadne                            |
| 38 | Tartiflette                          | Python     | https://github.com/tartiflette/tartiflette                    |
| 39 | Graphiti                             | Swift      | https://github.com/GraphQLSwift/Graphiti                      |
| 40 | GraphZahl                            | Swift      | https://github.com/nerdsupremacist/GraphZahl                  |
| 41 | Juniper                              | Rust       | https://github.com/graphql-rust/juniper                       |
| 42 | Async-graphql                        | Rust       | https://github.com/async-graphql/async-graphql                |
| 43 | graphql-ruby                         | Ruby       | https://github.com/rmosolgo/graphql-ruby                      |
| 44 | Agoo                                 | Ruby       | https://github.com/ohler55/agoo                               |
| 45 | Absinthe                             | Elixir     | https://github.com/absinthe-graphql/absinthe                  |
| 46 | graphql-elixir                       | Elixir     | https://github.com/graphql-elixir/graphql                     |
| 47 | Sangria                              | Scala      | https://github.com/sangria-graphql/sangria                    |
| 48 | Caliban                              | Scala      | https://github.com/ghostdogpr/caliban                         |
| 49 | Iacinia                              | Clojure    | https://github.com/walmartlabs/lacinia                        |
| 50 | graphql-cli                          | Clojure    | https://github.com/tendant/graphql-clj                        |
| 51 | alumbra                              | Clojure    | https://github.com/alumbra/alumbra                            |
| 52 | Morpheus GraphQL                     | Haskell    | https://github.com/morpheusgraphql/morpheus-graphql           |
| 53 | Mu-Haskell                           | Haskell    | https://github.com/higherkindness/mu-haskell                  |
| 54 | ocaml-graphql-server                 | OCaml      | https://github.com/andreas/ocaml-graphql-server               |
| 55 | graphql-erlang                       | Erlang     | https://github.com/jlouis/graphql-erlang                      |
| 56 | ghql                                 | R          | https://github.com/ropensci/ghql                              |
| 57 | gorm-graphql                         | Groovy     | https://github.com/grails/gorm-graphql                        |
| 58 | graphql-perl                         | Perl       | https://github.com/graphql-perl/graphql-perl                  |
| 59 | graphqld                             | D          | https://github.com/burner/graphqld                            |




How Threat Actors Fingerprint your GraphQL APIs

How Threat Actors Detect your GraphQL APIs Header.png

medium_How Threat Actors Detect your GraphQL APIs Header.png

small_How Threat Actors Detect your GraphQL APIs Header.png

thumbnail_How Threat Actors Detect your GraphQL APIs Header.png

Threat actors are after your APIs. Whether it’s your data that they’re interested in, or abusing your services for their financial gain.

Threat actors are after your APIs. Whether it’s your data that they’re interested in, or abusing your services for their financial gain. The reasons why threat actors target different organizations can vary, but one of the first steps they take in their hacking methodology is often consistent and predictable - **information gathering** or **reconnaissance**.

When hackers gather information on a target application, they do so both passively and actively. Passive information gathering does not involve sending packets to the targeted application - it involves gathering information through other channels that are indirect to the main application or the company operating it as a means to remain stealthy (but not only). For example, passive information gathering can be done by looking up the company’s name on GitHub in hopes of finding public repositories that could give them hints on what technologies are in use, or to find credentials that were hard-coded but forgotten about that they can then reuse.

Active information gathering involves communicating with the application, this requires the threat actors to send some traffic to the application. Imagine you are defending a large-scale application that serves millions of clients. You can appreciate how difficult it becomes to identify anomalous behavior if you don’t know what anomalous traffic could look like. Inigo’s solution not only allows cherry-picking those GraphQL queries that are targeting your application in a riskier way and surface the interesting ones to your security team, but also block and alert on them.

![How Threat Actors Detect your GraphQL APIs.png](/uploads/How_Threat_Actors_Detect_your_Graph_QL_AP_Is_26f3a8ef35.png)

## GraphQL Endpoint Detection
GraphQL introduces a shift in how clients request their data from applications using its innovative declarative query language. In GraphQL, clients express their intent using a query payload. If you ever used REST APIs, you may recall that in REST, a client’s intention is expressed by the combination of the HTTP method (GET, PUT, POST, DELETE) and the resource path (such as /v1/users).  For instance, a GET request to /v1/users would result in fetching the list of all users of a given application.

GraphQL, on the other hand, uses a single endpoint (such as /graphql) and some query to fetch a list of users. Such query could look like the following:
```
users {
   name
   email
}
```

So, how can threat actors discover whether an application is using GraphQL or another API technology? They do so by sending some query (the query does not have to be a valid one) to a list of possible endpoints that GraphQL may exist on, and observing the responses returned by the server.

For example, this is how a cURL request to a GraphQL endpoint could look like:
```
$ curl https://example.inigo.io/graphql -d '{"query":"query { users { name email } }"}' -H "Content-Type: application/json"
```

A typical GraphQL response is in JSON, and includes data or errors (or both) objects, which give away the fact this is a GraphQL API that responded:
```
{"errors":[{"message":"Cannot query field \"users\" on type \"Query\".","extensions":{"code":"GRAPHQL_VALIDATION_FAILED"}}]}
 ```

This method can then be automated so queries run against multiple endpoints in parallel. Possible endpoints could be:
- /graphql
- /query
- /api
- /playground
- /console
- /graphiql

If API versioning is in place, you may find GraphQL located in paths such as:
- /v1/graphql
- /v2/graphql
- /v1/query
- /v2/query
- /v1/console
- /v2/console

As you can see, APIs can be present in different locations. GraphQL servers can also be customized to point to a completely arbitrary location that isn’t on the list above. However, GraphQL API responses are often predictable, as dictated by the official GraphQL specification [Response Format](https://spec.graphql.org/October2021/#sec-Response-Format) section (7.1), allowing actors to identify that GraphQL is the interface which they are interacting with. Here is an excerpt of the response format section:

> A response to a GraphQL request must be a map.
If the request raised any errors, the response map must contain an entry with key errors. The value of this entry is described in the “Errors” section. If the request is completed without raising any errors, this entry must not be present.
If the request included execution, the response map must contain an entry with key data. The value of this entry is described in the “Data” section. If the request failed before execution, due to a syntax error, missing information, or validation error, this entry must not be present.
The response map may also contain an entry with key extensions. This entry, if set, must have a map as its value. This entry is reserved for implementors to extend the protocol however they see fit, and hence there are no additional restrictions on its contents.

This means that keys such as **data**, **errors** and **extensions** are all keys you may find in a GraphQL response. Armed with this knowledge, threat actors can build this logic into scanning tools to find where your GraphQL APIs live. In a future post, we will explore what threat actors might do after a GraphQL server was found.

When threat actors are performing an information gathering activity, they typically try different variations of queries. Some may be valid, some may not. Invalid queries could result in server exceptions. Inigo’s solution provides a layer of protection for your GraphQL APIs, our unique position in your architecture allows us to detect malformed queries against existent and non-existent endpoints and mitigate against such activity. Using our GraphQL Security and Management solution. Reach out to us for more information. 




How Threat Actors Detect your GraphQL APIs

large_inigo_joins_graphql_foundation.png

medium_inigo_joins_graphql_foundation.png

small_inigo_joins_graphql_foundation.png

thumbnail_inigo_joins_graphql_foundation.png

inigo_joins_graphql_foundation.png

Inigo is proud to announce it is the newest member of the <a target="_blank" href="https://graphql.org/foundation">GraphQL Foundation</a>, the powerful and supportive community dedicated to promoting the widespread adoption of GraphQL and accelerating the development of its surrounding ecosystem.

As a technology company fully focused on building the best and most secure GraphQL API experiences for developers, DevOps teams, and security architects, we are incredibly excited by Inigo's growing role in the GraphQL ecosystem. The open source data query language has proven—over and over again and at scale—that teams can confidently escape REST API limitations and build faster and more stable applications. Developers have largely driven the rise of GraphQL within their organizations, as they seek ways to more easily unlock the potential of APIs and harness more powerful developer tools.

Today, Inigo is proud to announce it is the newest member of the prestigious [GraphQL Foundation](https://graphql.org/foundation), the powerful and supportive community dedicated to promoting the widespread adoption of GraphQL and accelerating the development of its surrounding ecosystem. We join a select group of companies, including AWS, Meta, Twitter, Goldman Sachs, and PayPal, invested in the long-term success of GraphQL. Purpose-built to be an easy on-ramp that ensures teams can realize GraphQL’s full potential while hardening security around it, Inigo is closely aligned with the GraphQL Foundation’s goals. 

Inigo is a platform-agnostic, plug-and-play GraphQL API management platform that is ready to support any of the open source or commercial GraphQL servers available today. By doing so, Inigo evens the playing field wherever support gaps exist within particular GraphQL server options—ensuring that developers and organizations can be successful with the implementations of their choice. Additionally, Inigo provides visibility and analytics to help early adopters quickly master their GraphQL deployments and usage patterns. 

Developers and DevOps teams also gain the monitoring and observability tools they need to operate and scale GraphQL servers efficiently, and use real-time data to detect and avoid break change incidents. Inigo enhances developer experiences with CI/CD tooling that eliminates challenging custom builds and fixes, empowering developers to focus instead on core tasks. The GraphQL API management platform delivers high-throughput and low-latency that lets developers work faster, along with plug-and-play ease of integration (ready in 20 minutes or less). 

From a security perspective, Inigo automatically defends GraphQL attack surfaces from the full spectrum of cyberattacks, offering a developer-driven approach to enabling protections against GraphQL vulnerabilities. Inigo empowers security architects by providing declarative configuration and schema-based access control for introspection separation (with field and argument granularity).

The team at Inigo is excited to bring first-class capabilities to GraphQL users and offer developer-friendly alternatives to existing tooling—and especially now as a member of the GraphQL Foundation. Inigo is currently in beta, and eager to engage with early users to demonstrate how they can use the platform to supercharge their GraphQL visibility, operations, security, and success.

Inigo is a Proud New Member of the GraphQL Foundation

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 GraphQL's attack surfaces 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! [Join Early Acesss.](https://inigo.io/early-access)

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 - Security Guardrails for GraphQL Attack Surfaces

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! [Join Early Acesss.](https://inigo.io/early-access)

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! [Join Early Acesss.](https://inigo.io/early-access)

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

About

Blog

Login

Defeating Controls with Alias-based Query Batching

More posts

Defeating Controls with Alias-based Query Batching

Analysis of Public GraphQL Vulnerability Reports

What Makes Defending GraphQL APIs Challenging to Security Engineers

How Threat Actors Fingerprint your GraphQL APIs

How Threat Actors Detect your GraphQL APIs

Inigo is a Proud New Member of the GraphQL Foundation

All The Knobs - Security Guardrails for GraphQL Attack Surfaces

No, You Don’t Need to Disable Introspection

How Secure is Your GraphQL Server?

Join our Newsletter

Inigo

GQL Platform

Developers

Resources