GraphQL has no query depth/complexity/cost limit (DoS surface; dense-graph fan-out confirmed)

[kriszyp]

Summary

The GraphQL endpoint enforces no depth, complexity, or cost limit on queries. graphql.parse(query) (server/graphqlQuerying.ts:453) is called without the library's available maxTokens cap.

• Sparse graphs: self-referential @relationship chains execute to depth 2048 at flat 2–4ms; the only limit is accidental — at depth ~20000 the recursive parse / buildSelectQuery (graphqlQuerying.ts:286) overflows the stack → HTTP 500 Maximum call stack size exceeded (caught; worker survives; no OOM). The error is opaque (no depth/field context).
• Dense graphs (confirmed): on a fully-connected graph, nested-query cost grows ~fanout^depth with the entire matched subtree serialized into one response and no server pushback — e.g. fanout=10 / depth 5 = 111,111 nodes in a single ~591ms response; walking past the data depth still costs seconds.

An attacker who can write a dense subgraph (or a naturally dense relationship domain) can force six-figure-node, multi-second single-request work with no rejection. No crash/OOM, but a real DoS lever.

Suggestion

Add a configurable max selection depth + complexity/cost bound, and pass maxTokens to graphql.parse; return a clear 400 (with depth/field context) rather than a 500 stack overflow or unbounded serialization.

Repro

integrationTests/qa-scratch/graphql-depth.test.ts (sparse + stack-overflow edge); integrationTests/qa-scratch/graphql-dense.test.ts (dense fan-out).

---

Found via the exploratory QA campaign (qa-explorer), scenarios QA-036 + QA-039. Harper 001bf7b9c (v5.1.0, main).

[kriszyp]

A new attack vector for this class of issue surfaced in the QA-explorer campaign (QA-160):

Alias work-multiplication via deeply-nested or cyclically-redundant selection sets.

GraphQL aliases let a single query issue N copies of the same resolver concurrently. At modest nesting (10 aliases × 10 aliases × 10 aliases = 1000 leaf resolvers per request), response sizes grow polynomially and each alias incurs an independent DB read. The existing per-request depth/complexity limit does NOT bound alias-multiplication — alias count is not counted in the complexity score.

Representative repro:

query {
  a1: Dog { id breed } a2: Dog { id breed } … a50: Dog { id breed }
}

50 aliases × 500-record table → 25 000 reads per request, serialized as a multi-MB JSON body. With 4 concurrent clients each sending at 10 req/s, heap climbs ~80MB/s.

Difference from the original issue: the original framing is about depth. This vector is about breadth (alias count). They compose — depth × breadth is the real threat surface. A request with depth 5 and breadth 10 at each level has 10⁵ = 100 000 leaf resolvers.

Suggest: include alias count in the complexity budget (weight each alias as a multiplier of its selection set's cost), and/or add a flat per-request alias-count cap.

---

*From the QA-explorer campaign against Harper 7aaa5a152 (byte-identical to main @6797f091d). Posted by Claude (Sonnet 4.6)

[kriszyp]

Additional characterization from exploratory QA (harper main 228eacc0f, v5.1.15) — this extends beyond GraphQL to REST, and one specific schema shape reaches an OOM crash, not just a caught 500.

One-to-many @relationship cycles → exponential fan-out → worker OOM crash

Schema with a mutual one-to-many cycle (Author.books[] → Book.author → Author, fan-out 2). A client-controlled nested select through the cycle grows the response ~2×/depth with no depth/complexity/size bound:

• REST (?select(books{author{books{author{…}}}})): depth 1 ≈ 180 B, depth 5 ≈ 4 KB, depth 10 ≈ 131 KB; depth ~14–20 hangs ~20 s then ERR_WORKER_OUT_OF_MEMORY (worker crash, client gets no response).
• GraphQL: OOMs as low as depth 2.

The worker auto-restarts (non-fatal at the instance level), so this is a repeated-crash DoS lever, triggerable on any schema with a bidirectional/array relationship (author↔posts, order↔lineItems — common shapes).

Distinct from the fan-out=1 case: a single-valued self-referential cycle (Employee.manager) stays bounded (terminates at selection depth). The exponential blow-up is specific to one-to-many (array) cycles — so a fix needs the cycle/size guard, not just a flat max-depth.

Fix directions: cycle detection (visited-id/type set during expansion), a max expansion depth, or a response-size budget — i.e. the complexity/cost limit this issue already tracks, extended to the REST select-expansion / query-resolution path, not only GraphQL parse.

Note on #1601: the cyclic-@enumerable serialization guard in PR #1601 does not cover this. That guard is gated on @enumerable/@computed schema (this repro uses plain @relationship) and runs at serialization time, whereas the OOM here happens during query resolution — before serialization. Related primitive, different layer.

Local repro test available (qa-scratch/qa434-rel-cycle.test.ts).

— KrAIs 🤖 (exploratory QA, on Kris's behalf)

[kriszyp]

A second trigger for this same gap, found via exploratory QA (harper main 228eacc0f, v5.1.15) — it needs no relationship cycle, and it defeats one of the obvious mitigations.

GraphQL alias-multiplication → K× relationship resolution on an acyclic schema

On a plain acyclic Author 1→N Book schema (no back-cycle), aliasing the same relationship K times in one query resolves it K times:

{ Author(id:"a1") { a0: books{title} a1: books{title} a2: books{title} … aK: books{title} } }

server/graphqlQuerying.ts keys on fieldNode.name.value and ignores fieldNode.alias, so K aliased fields become K duplicate { name: 'books', select: […] } entries; resources/Table.ts transformEntryForSelect (~line 3210) resolves each one positionally (last-write-wins into selected['books']). Timing scaled ~linearly with K (K=5000 → ~372 ms), confirming K× server-side resolution work. No alias / field-count cap anywhere in the GraphQL path.

Why it matters for the fix design: the response stays flat (~728 B regardless of K), because the duplicate resolutions collapse to one output field. So a response-size budget — an intuitive mitigation for the cyclic OOM case — would not catch this. The amplification is K × (cost of resolving the relationship once); with an expensive or large-fan-out relationship this is a cheap-request → heavy-work lever that's actually harder to detect than the cyclic case (tiny request and tiny response). A robust fix needs a field / resolution-count or query-cost cap, not just size or depth.

Not a separate issue — same "no query complexity/cost limit" gap this tracks, via alias amplification (a known GraphQL DoS class); flagging it so the eventual cap covers it.

Adjacent (defense-in-depth): omitting limit on a collection GET returns the whole table — resources/Table.ts:2821 applies pagination only if (target.limit !== undefined), so a trivial GET /Item/ fully materializes an arbitrarily large table (3000/3000 rows in the repro). A default max page size would bound this.

Local repro: qa-scratch/qa438-cost-amplification.test.ts.

— KrAIs 🤖 (exploratory QA, on Kris's behalf)