Skip to main content

Depth limit

Description​

GraphQL does not limit how deep a query can be.

Since GraphQL schemas are often cyclic graphs, a query like the one below could technically be crafted:

query IAmEvil {
  author(id: "abc") {
    posts {
      author {
        posts {
          author {
            posts {
              author {
                # Can go on as deep as the client wants
              }
            }
          }
        }
      }
    }
  }
}

This can lead to potential DoS attacks or information leakage.

Remediation​

Secure your application by preventing clients from abusing query depth. To do so, add a Maximum Query Depth limit based on your knowledge of the schema and how deep you believe a legitimate query could go. By analyzing the query document's abstract syntax tree (AST), a GraphQL server is able to reject or accept a request based on its depth.

For instance, using graphql-ruby with the max query depth setting set to 3 gives the following result:

errors:
- message: Query has depth of 6, which exceeds max depth of 3

Since the document's AST is analyzed statically, the query does not even execute, which adds no load on your GraphQL server.

Depth alone is often not enough to cover all abusive queries. For example, a query requesting an enormous amount of nodes on the root will be very expensive but unlikely to be blocked by a query depth analyzer.

GraphQL Specific​

Apollo

For the Apollo framework engine, ensure that you are implementing depth limiting to prevent overly complex queries from overloading the server. This can be achieved by using a validation rule that checks the depth of each query and rejects those that exceed a certain threshold. Libraries such as graphql-depth-limit can be used to easily set up depth limiting in your Apollo server configuration.

Yoga

Ensure that the Yoga framework engine is updated to the latest version to mitigate any known vulnerabilities. Regularly review and apply security patches as they become available. Additionally, implement proper input validation to prevent injection attacks and configure the engine with secure defaults to minimize the risk of misconfiguration. Always follow best practices for authentication and authorization to protect sensitive data and resources.

Awsappsync

To prevent issues with depth limits in AWS AppSync, it is recommended to define and enforce depth limiting on your GraphQL operations. This can be achieved by setting a maximum depth for queries in the AWS AppSync settings. Additionally, consider implementing cost analysis to ensure that queries do not exceed complexity that can impact performance. By using these strategies, you can protect your API against overly complex queries that could lead to performance degradation or abuse.

Graphqlgo

To mitigate potential security vulnerabilities in the GraphQL Go framework engine, it is recommended to implement depth limiting on queries. Depth limiting restricts the complexity of the queries that can be executed by setting a maximum depth for each query. This prevents malicious users from crafting deeply nested queries that could potentially lead to performance issues or denial of service. To enforce depth limits, you can use middleware or custom logic that analyzes the query's abstract syntax tree (AST) before execution and rejects queries that exceed the specified depth threshold.

Graphqlruby

In the GraphQL Ruby framework, to mitigate the risk of overly complex queries that can lead to performance issues or denial of service, implement a depth limit for queries. You can use the max_depth option in your schema definition to enforce a maximum depth for incoming queries. This will ensure that users cannot submit queries that exceed a certain level of nested fields, which can protect your application from unnecessary load and potential abuse. Additionally, consider using the graphql-depth_limit gem for more advanced depth limiting features.

Hasura

To mitigate potential security risks in the Hasura framework engine, ensure that all GraphQL queries are validated against a strict schema and implement role-based access controls (RBAC) to limit permissions based on user roles. Additionally, use prepared statements or parameterized queries to prevent injection attacks, and regularly update the Hasura engine to the latest version to benefit from security patches and improvements.

Configuration​

Identifier: resource_limitation/graphql_depth_limit

Options​

  • threshold : Maximum depth before raising an alert (-1 = infinite).

Examples​

Ignore this check​

checks:
  resource_limitation/graphql_depth_limit:
    skip: true

Score​

  • Escape Severity: MEDIUM

Compliance​

  • OWASP: API4:2023

  • pci: 6.5.1

  • gdpr: Article-32

  • soc2: CC6

  • psd2: Article-95

  • iso27001: A.14.2

  • nist: SP800-53

  • fedramp: SC-5

Classification​

  • CWE: 400

Score​

  • CVSS_VECTOR: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:H/RL:O/RC:C
  • CVSS_SCORE: 5.1

References​