How do you choose which GraphQL abuse controls to run at each phase for a public endpoint?

### Frame it as a budget, not a checklist Controls are usually presented as a list to adopt. That framing produces stacks that are simultaneously over-defended in cheap places and undefended where it matters. The useful frame is that every control has three properties: the *information* it needs (which fixes its earliest possible phase), the *cost it imposes on legitimate traffic* (paid on every request), and the *certainty of its verdict* (how often it rejects something that was fine). At a 1,200-request-per-minute peak, a control adding two milliseconds costs about 2.4 seconds of aggregate latency a minute, forever, to stop something that may arrive twice a week. That is often still worth it - but it is a decision, and it should be made explicitly. ### Tier by tier, with what each tier cannot do **Outside the service** - a reverse proxy, a load balancer or a CDN - you can enforce anything computable from bytes and headers: request size, connection and request rate, TLS and origin policy, and a required `application/json` content type. What you cannot do there is anything about the document, because that component does not parse GraphQL and does not hold the schema. Teams periodically try to move the depth cap outward; the honest answer is that doing so means running a second GraphQL implementation with a second copy of the schema to keep in sync, and the sync is where it will fail. One trap belongs to this tier specifically. Response caching keyed on the request body is attractive here and quietly wrong for a graph where different fields have wildly different freshness needs. A cached seat-map response makes `seatsRemaining` a field that returns stale data - a caller sees 47 seats on a tier that sold out ninety seconds ago and starts a checkout that cannot complete. Freshness is a per-field property, and a cache placed before the parse cannot see fields at all. **At the service edge, before parsing**, you authenticate the caller and, if you have one, resolve a registered document identifier. This is the highest-leverage placement available, because it decides whether attacker-controlled text ever reaches your parser. **At validation**, you get the document and the schema and none of the runtime world. Prefer controls with crisp verdicts here - a depth cap, a total field-count cap, a cap on operations per document, a refusal of introspection - and treat a static cost score as the expensive, powerful, high-maintenance option it is: it needs per-field weights, it needs re-tuning whenever the schema changes, and it produces the false rejections that generate the support tickets. **At execution**, place the controls that need reality: a per-operation deadline, per-object authorization, caps on concurrent backend work, and batching that bounds the calls one field can fan out into. ### The one strategic fork Everything above assumes an open endpoint. The alternative reshapes the whole stack: register every document the first-party clients use, and reject anything not on the list. Depth, breadth, alias and cost limits become nearly redundant, because the set of possible documents is finite and reviewable before release. What you pay is coupling - a client cannot ship a new query without a registration step - and the loss of arbitrary third-party callers, which for many products is the entire point of exposing a graph. The honest answer is usually both: register the documents your own applications use and admit them by identifier, while keeping a limited, cost-bounded open path for partners, with different budgets on each. Say which you are choosing and why, because that is the judgement the question is asking about. ### Calibrating rather than guessing Caps chosen from a blog post reject real traffic. Measure first: log observed depth, field count and static cost for a week of real operations, set the initial caps above the observed 99.9th percentile, and run every new limit in report-only mode before it rejects anything. Alert on rejection rate, not just on attacks, because a spike after a client release is far more likely to be your own team than an adversary. ### What to concede A good principal answer names the residual risk. A static score bounds the *shape* of a document, not the work it causes; a shallow, cheap-looking operation over a badly indexed table will pass every pre-execution control you have. Deadlines and backend concurrency caps are what catch it, which is why they are not optional even on an endpoint with an excellent cost limiter. And no static control ever compensates for a missing authorization check - a perfectly bounded, promptly executed, correctly sized request that reads someone else's data is still a breach.