Should Keystone enforce GraphQL query depth limits by default?

[n0wsh]

Context

Multiple independent security researchers (myself and @nedlir) have independently identified that Keystone's GraphQL API has no query depth limiting, complexity analysis, or cost budgeting.

A single unauthenticated request with a deeply-nested circular relationship query (e.g. users → posts → author → posts → author → ...) triggers exponential database queries. In local testing against a SQLite database with 6 total records, a depth-16 query caused a 38-second server hang.

This is classified as CWE-400: Uncontrolled Resource Consumption.

What other GraphQL frameworks do

Framework	Default depth limit	Complexity analysis
Hasura	Yes (built-in)	Yes
PostGraphile	Configurable	Yes (cost analysis)
graphql-ruby	max_depth + max_complexity	Yes
Lighthouse (Laravel)	Yes (configurable)	Yes
Keystone	None	None

Reproduction

Any Keystone project with bidirectional relationships (the standard pattern):

# No authentication required (with allowAll access)
{
  users {
    posts {
      author {
        posts {
          author {
            posts {
              author {
                posts {
                  author { id }
                }
              }
            }
          }
        }
      }
    }
  }
}

Measured response times (SQLite, 1 user + 5 posts + 15 comments):

Depth	Time
12	0.9s
14	4.2s
16	38s (timeout)

Proposal

Add a default query depth limit (e.g. 10) using graphql-depth-limit or equivalent, with a configuration option:

export default config({
  graphql: {
    maxDepth: 10, // default, configurable
  },
})

Questions

1. Should Keystone ship with a default query depth limit?
2. Should this be treated as a security advisory or a hardening improvement?
3. What default depth limit would be appropriate?

cc @nedlir @dcousens

[dcousens]

I am open to the discussion, adding defaults can have as many upsides as downsides; so I'd prefer to hear from the community before coming to a random set of numbers and/or set of included default strategies.

Related resources

https://github.com/keystonejs/keystone/tree/main/examples/limits could use some attention to show how developers can utilise more advanced techniques.

https://github.com/keystonejs/keystone/blob/main/tests/api-tests/queries/limits.test.ts isn't bad, but it's DIY.

https://keystonejs.com/docs/config/lists#graphql has .maxTake, but can be somewhat limited except insofar as using it to inform other strategies as shown in our tests.

[nedlir]

As the initial reporter of this vulnerability (GHSA-c287-g46c-6235), I want to reinforce why this is categorized as a security flaw (CWE-770) rather than a configuration preference.

Industry precedents like GitLab (CVE-2025-10004) and Parse Server (CVE-2026-30946) demonstrate that providing the capability to add limits is insufficient if the "out-of-the-box" state allows for unauthenticated Denial of Service.

To address the concern regarding breaking changes, I suggest implementing at least a Soft Limit approach for the current version:

1. Console Warnings: Emit a warning whenever a query exceeds a suggested depth (e.g., 8–10) if no maxDepth is explicitly defined.
2. Startup Validation: Print a "Missing Query Depth Security Configuration" notice at server start if these limits are absent.

But please note that this is just the first step and there should be a mechanism that limits the depth by default like a dedicated graphQL-limit library or logic (this was done in the examples I showed. It was either this or usage of Apollo Server plugin - createComplexityValidationPlugin which is doing just that).

[philipheinser]

I disagree that the maxDepth approach is meaningful. you can have a very slow virtual field at depth one and have the same problem of slow/heavy to realsove field. IMO it's not security vulnerability. How is it uncontrollable when you can set auth rules? # No authentication required (with allowAll access). Also you are free to wrap the graphql api form keystone with plugins / rate limit / etc.