With GraphQL introspection disabled, what can a caller still infer about the schema?

## Start with what "disabled" actually means The specification defines the introspection system and expects servers to answer it; it defines no way to switch it off. Every implementation that offers the switch does the same unspecified thing: a validation rule that rejects any document selecting `__schema` or `__type` on the query root. That is a narrow change. Parsing is untouched, the rest of validation is untouched, execution is untouched, and every other meta-field is untouched. Knowing that, you can predict what leaks without testing it. ## Channel one: validation error text This is the channel that surprises people, and it is the one an interviewer is usually fishing for. The specification requires that a document naming a field that does not exist on the selected type fail validation. It says nothing about the message. Many implementations, following the one most others were modelled on, produce something like `Cannot query field "privilegedNotes" on type "Case". Did you mean "privilegedNoteCount"?`. That single string confirms the type `Case` exists, confirms `privilegedNotes` does not, and hands over a real field name that was never guessed. **This is a convention of implementations, not a rule of the specification** — which is exactly why it can be turned off without breaking conformance. Suggestions are not the only leak in that text. Unknown-argument errors name the arguments a field does accept. A variable used in the wrong position produces an error naming the expected input type, so `$filter` typed as `String` reveals `CaseFilterInput`. A missing required argument is reported with the argument's name and its non-null type. String-similarity suggestions also appear for type names in fragment conditions and for enum values in some implementations. And every one of these is cheap. A validation failure is a *request error*: the response carries `errors` and no `data` key, and no resolver ever runs — so probing is fast, leaves no business-logic trace, and costs the attacker nothing worth rate-limiting against. Walking a legal case-file graph from three known root fields to a workable map of its `Case`, `Filing` and `PrivilegedNote` types is a scripted afternoon, not research. ## Channel two: `__typename` `__typename` is a meta-field available on every object, interface and union selection, and a server that blocks introspection by rejecting `__schema` and `__type` almost never blocks it — clients depend on it to discriminate abstract results, and normalized client caches use it as part of a cache key. Selecting it on a field whose declared type is an interface or union returns the concrete type name, so the shape of an abstract branch of the schema can be enumerated from live results without touching introspection at all. ## Channel three: everything already outside the server A browser client's JavaScript bundle contains the text of every operation it sends, along with the fragments and variable types they use. A mobile binary can be unpacked for the same strings. Public developer documentation, a schema published to a registry for partners, an error `extensions` entry carrying a schema-aware code, a status page describing a new feature — all of them describe the schema. If your own product ships the documents, the portion of the schema your product uses is public whatever the endpoint answers. ## What actually narrows it Ranked by what each one buys: 1. **Authorize fields during execution.** This is the only control that changes what a caller can *do*. Everything else changes what they can *learn*. 2. **Allowlist operations.** If the server only executes documents registered ahead of time, an unregistered probe is rejected before validation ever reports a field name, which closes the error-text oracle as a side effect. The mechanics of that control belong to its own topic; here it is simply the strongest answer. 3. **Suppress suggestion hints and keep validation messages generic.** Cheap and effective against enumeration, with a real cost: your own developers lose the message that would have told them they typed the field name wrong. Teams often keep suggestions on in non-production deployments and off in production. 4. **Disable introspection.** Worth doing on an endpoint whose callers are all first-party, but as the last item on this list rather than the first. ## The honest summary Disabling introspection converts a one-request schema dump into a scripted enumeration exercise. That is a genuine increase in attacker cost and it is not nothing. It is also not a boundary, because none of these channels leak anything an attacker could not eventually infer, and none of them are what stops an unauthorized operation from executing.