Validation errors can be used to get schema details

Similar to introspection, another way to probe a server for details about its schema is to submit invalid GraphQL documents so that the default validation rules provide data back. A variety of rules use didYouMean.js to give the developer suggestions about possible changes to get a valid document. This is ideal when developing against an API, but also is a channel for leaking information (like prototype features) with validation rules like FieldsOnCorrectType.

In production, some companies with internal schemas elect to disable introspection, where internally they can acquire their schema via other channels. Seemingly security through obscurity.

The validation rules still need to run, but it would be ideal if we could toggle the ability to provide suggestions as part of the error message. The ValidationContext does provide onError handler, but it seems a bit reactive and wasteful to then remove the computed suggestionList. This also ties into some ideas outlined in https://github.com/graphql/graphql-js/pull/2074.

For example, Apollo Server provides a convenient constructor option introspection flag to determine if an introspection query should be allowed. It would be an improved developer experience if this flag could inform the underlying GraphQL.js validation rules to restrict its error messaging without any additional configuration required.

[leebyron]

I don’t really have a crisp proposal - just trying to clarify the need.

That seems like a reasonable way to implement introspection blocking, though I would worry about a theoretical misuse that creates a security risk where a query skips validation in some way and is still executed and exposes introspection. It might be nice if this was implemented within GraphQL.js that in addition to the clear error, it also simply wasn’t possible to execute introspection queries on a schema with introspection disabled.

My concern with granular controls is that a user would disable introspection but not consider disabling didYouMean and inadvertently open this internal information leak. I would expect that a schema with introspection disabled would also disable didYouMean.

I can’t think of a reason why you would want to disable introspection but enable didYouKnow or vice-versa.

[leebyron]

Based on the OP intent, should there be a single flag to disable introspection that also disables didYouMean?