Two GraphQL requests can have similar sizes while creating very different work for the server. One might retrieve a profile. Another might traverse several relationships and return many records at each level. Counting requests alone does not measure that difference.
Availability controls need to account for the operations behind the query. The same review also has to verify authorization at the objects and fields those operations return.
Depth is only one part of cost
OWASP's GraphQL guidance discusses query complexity, depth limits, timeouts, rate limiting, and batching considerations. These mechanisms address different ways a request can expand server work. The GraphQL security guidance describes the available controls.
An illustrative customer dashboard requests an account's projects, each project's tasks, and each task's comments. The query may have a modest depth while returning a large number of records. Aliases and multiple operations can also repeat work without adding deeper nesting.
Establish a workload budget
Define supported pagination sizes, maximum concurrent work, and limits for expensive fields. A cost model can assign different weights to operations that trigger database scans, external calls, or computation. The model needs to reflect the implementation rather than only the number of visible fields.
Record where enforcement happens. Rejecting a query before resolver execution has different resource implications from allowing it to run until a timeout. A timeout also needs cancellation behavior so abandoned queries do not continue consuming downstream capacity indefinitely.
Test representative expansion patterns
Use synthetic data and a dedicated environment with explicit resource limits. Compare a normal dashboard query with controlled increases in depth, list size, aliases, and batching. Measure resolver calls, database work, latency, and rejection behavior. Avoid unrestricted load tests against production.
Then run a normal query from a second test tenant while the first reaches its limit. This checks whether one customer's workload affects another's expected service. A per-request cap may still permit excessive aggregate work across many concurrent requests.
Keep authorization in the same review
Resolver reuse can make a field accessible through several query paths. Test whether each path applies the same object and field permissions. Disabling introspection or obscuring field names does not establish authorization; a caller who knows the schema can still request the operation.
The resulting assessment can identify the enforced workload limits, the expansion patterns tested, and any inconsistent access checks. For the business, the decision is whether the supported query surface delivers the intended customer functionality within the measured resource budget and access boundaries. Changes to resolvers, data volumes, or external integrations can require the cost assumptions to be revisited.
Sources
GraphQL: Security. The customer dashboard and workload measurements are illustrative.
