A county GraphQL endpoint applies a per-HTTP-request rate limit, yet a single request can batch many aliased operations. What control gap should the tester highlight?
Select an answer to reveal the explanation.
Short Explanation
Counting cars while ignoring buses packed with riders undercounts traffic. A GraphQL batch can hide many operations inside one HTTP request, so request-only rate limits miss the abuse. Turning off introspection is not a quota system.
Full Explanation
A county GraphQL endpoint that rate-limits per HTTP request while allowing a single request to batch many aliased operations has a control gap: abusive clients can amplify work inside one counted request. Rate limits must account for operation count, complexity, or depth—not merely HTTP request volume.
Claiming GraphQL cannot be rate-limited under any design is false; complexity-aware limits are common. Treating batching as proof of immunity to authorization bugs confuses transport efficiency with access control. Disabling introspection does not enforce fair-use quotas by itself.
Exam caveat: introspection hardening and authorization are separate from DoS/complexity controls; all three matter for civic APIs.
Operational check: send a single authorized request with many aliased fields or batched operations, compare server cost and rate-limit counters, and document bypass of naive per-request limits. Recommend operation and complexity budgets aligned to county API capacity. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next release window that the same control still holds under the application's current auth model.