Control Placement by Phase

### What the specification actually contains The GraphQL specification is a document about *language and evaluation*. Its sections describe: the syntax of a GraphQL document (operations, selection sets, fragments, arguments, variables, directives); the type system (object, interface, union, enum, input object, scalar, plus the non-null and list wrappers); introspection (the `__schema`, `__type` and `__typename` meta-fields); a numbered list of validation rules a document must satisfy against a schema; the execution algorithm (how fields are collected, how resolvers are invoked, how values are completed, how errors propagate); and the response format, with its `data`, `errors` and `extensions` keys. Read that list again and notice what is missing. There is no notion of a caller. No credentials, no roles, no sessions. No budget of any kind - no maximum depth, no maximum number of fields, no cost model, no request quota, no timeout. No rules about how large a request body may be, how many operations may arrive together, or how long a subscription may stay open. A server that accepts a two-thousand-level-deep document and spends forty seconds resolving it is fully conformant. ### The rules that look like security, and what they really do A few specified validation rules get mistaken for protection. The most famous is that fragment spreads must not form cycles: without it, a fragment that spreads itself would let a short document describe an infinitely large selection. That rule exists so that a *finite document text* always expands to a *finite selection*. It is a well-formedness rule, not a cost rule - a legal, acyclic document can still select a million fields. Similarly, fields must exist on the type they are selected against, leaf fields must not carry a selection set and composite fields must, arguments must be of the declared type, and variables must be defined and used. All of these bound *legality*, and they bound it before any resolver runs, which is genuinely useful. None of them bound *work*. ### Introspection is a feature, not a hole the spec left open The specification defines introspection as part of the type system, and describes no mechanism for turning it off. Refusing `__schema` in production is therefore something a server layers on top of the specification, not a configuration the specification anticipates. That matters for the placement discussion: because introspection is just ordinary fields in the schema, a server that wants to refuse it does so with its own rule over the parsed document, in the same place its other document-shaped limits live. ### The transport is a separate document GraphQL deliberately says nothing about HTTP. The conventions everyone shares - `POST` with a JSON body carrying `query`, `variables` and `operationName`; `GET` with the operation in the query string; the `application/json` and `application/graphql-response+json` media types; which status codes accompany which failure - are specified in the *GraphQL over HTTP* working draft, which is a different document and still a draft. The closest thing in the whole ecosystem to a specified security rule lives there: that `GET` should carry only query operations, never mutations. Treat that as near-settled convention with a spec behind it, and say so rather than attributing it to "the GraphQL spec". ### Why the specification's silence is the whole subject Because nothing is specified, every control on a GraphQL endpoint is something you built and attached at a phase you chose. Two conformant servers can behave completely differently under abuse, and a control placed at the wrong point in the pipeline is either uninformed or has already paid for the work it was supposed to prevent. The specification does hand you one enormous gift for security, though, and a good answer says so. A GraphQL request arrives as a *statically analysable document* checked against a *fully typed schema* before a single resolver runs. You can compute a bound on what an operation will ask for without executing any of it - which is exactly what depth caps, field-count caps and cost scores exploit. REST gives you no equivalent: you cannot look at `GET /venues/7813` and know how much of the object graph the handler will walk. So the specification gives you no controls, but it gives you the one property that makes strong pre-execution controls possible at all. ### How to say this in an interview Start with the flat answer - the spec defines no security - then show you know the boundary precisely: type system, validation, execution, response shape are in; identity, budgets and transport are out; the structural validation rules bound legality, not cost; and the typed, pre-executable document is the lever every real control pulls.