Analiza kosztu zapytań i ograniczanie głębokości

REST endpoints have a fixed cost: you call /users/1/posts and the server decides how much work that is. GraphQL flips control to the client. A single endpoint accepts arbitrary nested queries, so a malicious or careless client can ask for something enormous.

Consider a query that walks user -> friends -> friends -> friends .... Each level multiplies the number of resolvers fired. A few hundred bytes of query text can trigger millions of database round-trips.

• Depth limiting caps how deeply nested a query can be.
• Complexity scoring caps the estimated total cost.
• Persisted queries only allow pre-approved query documents.

In this lesson we build all three for a Strawberry + FastAPI service.

The classic abuse is a deeply nested, self-referential query. If your schema lets Author resolve posts and Post resolve author, a client can ping-pong between them indefinitely.

Below is the shape of such a query as plain text. Even without running it, notice that every extra posts { author { ... } } level can multiply fan-out at the data layer.

Counting braces in text is unreliable (string literals, fragments, aliases all break it). The correct way is to walk the parsed AST that graphql-core produces. Each FieldNode with a nested selection set adds one to the depth.

Here is a standalone, dependency-free walker that computes the maximum selection depth of a nested structure. It mirrors how a real validation rule recurses.

GraphQL exposes a validation phase that runs after parsing but before execution. If any validation rule reports an error, execution never starts, so no resolvers fire. This is exactly where depth limiting belongs.

The graphql-core library ships a ValidationRule base class. We override enter_operation_definition to measure depth and append a GraphQLError when the limit is exceeded.

Strawberry's Schema accepts an extensions list and forwards extra validation rules through its execution config. The cleanest path is the AddValidationRules extension, which injects custom rules into every request.

Because depth validation happens before resolvers run, an over-deep query is rejected with a 400-style GraphQL error and zero database work.

Depth limiting stops vertical abuse, but it ignores horizontal abuse. A query only 2 levels deep can still be catastrophic:

• search(first: 100000) returns a huge list.
• Requesting 50 sibling fields at the same level multiplies resolver work.
• Aliasing the same expensive field 100 times bypasses naive per-field caps.

To cover these we need complexity scoring: assign each field a cost, multiply by list-size arguments, and sum the whole tree. Reject when the total crosses a budget.

The core idea: walk the query tree, give each field a base cost (default 1), and multiply a subtree's cost by any first/limit argument it carries. A list field that fetches 100 items and contains 3 sub-fields costs roughly 100 * 3.

This standalone estimator captures that multiplier logic so you can reason about budgets before plugging it into a framework.

Hard-coding cost 1 everywhere is too blunt. Some fields are cheap (a string column) and some are expensive (a fan-out join or an external API call). In production you annotate each field with its own weight.

A common pattern is a metadata dictionary keyed by field name, looked up during scoring. Strawberry lets you attach such metadata via field directives or a custom extension that reads from a registry like the one below.

To enforce complexity in Strawberry, write a SchemaExtension that hooks on_validate (or on_operation). It computes the score from the parsed document and raises a GraphQLError if the budget is blown, halting before execution.

Keep the budget configurable per client tier: anonymous traffic gets a small budget, authenticated partners get more. The score and budget are great metrics to log and alert on.

Depth and complexity limits are heuristics. The strongest control is the persisted query allowlist: clients send only a hash, and the server executes only documents it has pre-registered (usually extracted from your own frontend at build time).

Arbitrary ad-hoc queries are rejected outright, so attackers cannot craft anything new. The client sends {"extensions": {"persistedQuery": {"sha256Hash": "..."}}} and the server resolves it from a store.

These controls are complementary, not alternatives. A hardened FastAPI + Strawberry gateway typically stacks them in this order:

• Persisted queries first — in strict mode, reject anything not on the allowlist before parsing.
• Depth limit — cheap structural guard during validation.
• Complexity budget — weighted cost ceiling, tiered per client.
• Rate limiting — cap requests per token/IP at the FastAPI middleware layer.

Validation runs before resolvers, so depth and complexity rejections cost almost nothing. Always return the computed score in logs so you can tune budgets from real traffic instead of guessing.

A client sends a query that is only 2 levels deep but uses search(first: 50000) and selects 30 sibling fields under each result. Your server has a depth limit of 10 but no complexity scoring. What happens?

You now have a layered defense against abusive GraphQL queries on FastAPI + Strawberry:

• Depth limiting walks the AST during the validation phase and rejects over-nested queries before any resolver runs.
• Complexity scoring assigns weighted, per-field costs and multiplies by list-size arguments to enforce a budget, catching wide and aliased queries that depth misses.
• Persisted queries allowlist hashed documents so only pre-approved queries execute — the strongest guarantee.
• Stack them with rate limiting, tier budgets per client, and log the computed scores to tune limits from real data.

Remember the key trade-off: depth guards vertical abuse, complexity guards horizontal abuse, and persisted queries eliminate the unknown entirely.