An operation allowlist fixes which documents run — what abuse still arrives through variables?

## Shape versus values An executable document has two halves. The **shape** is fixed text: which fields are selected, how deep the selection goes, which fragments are spread, which arguments exist. The **values** arrive per request, as `variables`. An operation allowlist governs the first half completely and the second half not at all. Candidates who have only read about allowlists routinely miss this, because the mechanism is described as "only approved queries run" and *approved* sounds like *safe*. Take a registered document from a hospital appointment graph: ```graphql query ClinicSchedule($clinicId: ID!, $first: Int!, $status: AppointmentStatus) { clinic(id: $clinicId) { name appointments(first: $first, status: $status) { id scheduledFor patient { id displayName } } } } ``` This document was reviewed, hashed and registered. Everything below is a request that the allowlist admits without hesitation. ## The four things that still arrive **A hostile magnitude.** `first: 25000` is a valid `Int`. The declared type constrains the kind of value and the 32-bit range the specification gives `Int`; it does not express a sane maximum. The single most common gap after an allowlist rollout is an uncapped list-slice argument, because the document "looks small" — one field, three subfields — while the work it triggers is set at request time by the caller. A server-side clamp, applied in the resolver or the data layer rather than trusted from the client, is the fix. **A record the caller may not see.** `clinicId: "clinic_4471"` is an identifier for a clinic in another region. Nothing about registering the document decided who may read that clinic's schedule. Authorization has to run during execution, on the edges actually traversed — the clinic, then each appointment, then each patient — not once on the entry field. A registered document is a very convenient vehicle for enumeration precisely because it is guaranteed to be accepted: an attacker with a valid session iterates identifiers and reads what comes back. **A value that reaches a backend.** A free-text `$search` or a `$sortBy` variable that is interpolated into a downstream query is untrusted input that happens to have passed through an approved document. The allowlist did not sanitise it, parameterise it, or bound its length. **Volume.** The document is cheap; ten thousand executions of it a minute are not. Per-caller rate limits and concurrency budgets are unaffected by membership, and after an allowlist rollout they often become the *only* remaining brake, because everything about the document is now fixed and the attacker's only free variables are values and frequency. ## Membership is not a budget The second half of the misconception: teams sometimes drop depth and cost controls after enforcing an allowlist, on the reasoning that every document was reviewed. A 19-level-deep document that someone registered eleven months ago during a spike is allowed at 19 levels for as long as it stays in the set, and it will not be re-examined by anything on the request path. Membership is a boolean; it carries no score, no expiry and no memory of why it was approved. The corollary is the real prize, and it is what a senior answer should reach for. Because the set is **finite and known before traffic arrives**, the expensive analysis moves off the hot path. Each document can be scored once, at registration, against the worst variable values the server will accept — and that qualifier matters, because a score computed with `first: 25` for a document that permits `first: 25000` is a fiction. A document that scores badly is refused at the registration gate, where the failure is a build error for one team rather than a runtime rejection for real users. This is the strongest operational argument for allowlists and it is the one candidates least often make. ## Designing the residual controls A good answer names where each surviving control lives: - **Range and shape of values** — coerced by the schema for type, clamped by the server for magnitude, with the clamp expressed once in the data layer rather than repeated per resolver. - **Ownership** — checked on every resolved edge during execution, because one object is reachable through several traversals and only the edge knows the caller's relationship to it. - **Frequency** — per caller and per credential, on the operation name or document identifier, which an allowlist actually makes easier: with a fixed set you have a stable, low-cardinality key to limit and to chart. - **Registration-time review** — the one control the allowlist adds, and the one that only works if somebody is genuinely reading what gets registered. ## How to answer it Open with the distinction — shape fixed, values free — then give one concrete registered document and three concrete hostile variable bindings for it. Close on the asymmetry: the allowlist removed the attacker's ability to *write* the request, so everything they can still do lives in the values and in the rate, and that is exactly where the remaining budget of your defensive effort should go.