limits

The limits configuration allows you to set various limits on incoming GraphQL requests to prevent too large operations that could lead to overfetching or DOS attacks.

Learn more about operation complexity and why limiting it is important.

Options

max_depth

This configuration allows you to set a maximum depth for incoming GraphQL queries. Queries that exceed this depth will be rejected with an error. If not specified, there is no limit on query depth.

n

• Type: integer

The maximum allowed depth for incoming GraphQL operations.

disable_introspection

• Type: boolean
• Default: false

When set to true, introspection queries will not be exempt from the depth limit. This means that introspection queries will also be subject to the maximum depth restriction. This is usually set to true when you want to fully enforce depth limits, including for introspection queries. But be aware that this may break tools that rely on introspection, because they often generate deep queries to explore the schema.

flatten_fragments

• Type: boolean
• Default: false

When set to true, the depth calculation will consider fragment spreads as if they were inlined. This provides a more accurate depth measurement, especially when fragments are used extensively in operations.

max_directives

This option allows you to set a maximum number of directives allowed in incoming GraphQL operations. Operations that exceed this number will be rejected with an error. If not specified, there is no limit on the number of directives.

n

• Type: integer

The maximum allowed number of directives in incoming GraphQL operations.

max_tokens

This option allows you to set a maximum number of tokens allowed in incoming GraphQL operations. Operations that exceed this number will be rejected with an error. If not specified, there is no limit on the number of tokens.

n

• Type: integer

The maximum allowed number of tokens in incoming GraphQL operations.

max_aliases

This option allows you to set a maximum number of aliases allowed in incoming GraphQL operations. Operations that exceed this number will be rejected with an error. If not specified, there is no limit on the number of aliases.

n

• Type: integer

The maximum allowed number of aliases in incoming GraphQL operations.

Examples

Limit Query Depth to 2

limits:
  max_depth:
    n: 2

In that example, any incoming GraphQL operation that exceeds a depth of 2 will be rejected with an error.

query {
  user {
    posts {
      comments {
        text
      }
    }
  }
}

The above query has a depth of 3 (user -> posts -> comments), so it would be rejected.

Limit Directives to 5

limits:
  max_directives:
    n: 5

In that example, any incoming GraphQL operation that contains more than 5 directives will be rejected with an error.

query {
  user @include(if: true) {
    posts @skip(if: false) {
      comments @include(if: true) {
        text @skip(if: false)
      }
    }
  }
}

The above query contains 4 directives, so it would be accepted. If an operation contained more than 5 directives, it would be rejected.

Limit Tokens to 10

limits:
  max_tokens:
    n: 10

In that example, any incoming GraphQL operation that contains more than 10 tokens will be rejected with an error.

query {
  user {
    id
    name
  }
}

The above operation contains 8 tokens, so it would be accepted. If an operation contained more than 10 tokens, it would be rejected.

Limit Aliases to 3

limits:
  max_aliases:
    n: 3

In that example, any incoming GraphQL operation that contains more than 3 aliases will be rejected with an error.

query {
  user1: user {
    id
  }
  user2: user {
    name
  }
}

The above operation contains 2 aliases (user1 and user2), so it would be accepted. If an operation contained more than 3 aliases, it would be rejected.

query {
  user1: user {
    id
  }
  user2: user {
    name
  }
  user3: user {
    email
  }
  user4: user {
    age
  }
}

The above query contains 4 aliases (user1, user2, user3, and user4), so it would be rejected.