You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I want to allow introspection on my supergraph but I do not want to keep it open for attackers to abuse and run custom or abusive introspection operations. This can lead to cache blowout or coprocessor overload. Instead we should restrict introspection to return a fixed response.
Describe the solution you'd like
There are a few possible outcomes, but as a valid client doing introspection the result I need is the JSON response of an introspection result
We could restrict the GraphQL operation to a fixed operation, that must match by hash (See below).
We could provide a new, fixed endpoint to get the JSON response /introspection
We could provide a new, fixed endpoint to get the SDL text response /sdl (this would require clients to process but still provides the schema)
We could analyze the request for the number of recursive nodes and have logic to determine if it not a good faith introspection query, like graphql-java did.
Hard code the introspection query as a saved operation in Router, ideally matching the one returned from graphql-js, and only allow that as a valid introspection option. This can be used then to return the result or from a fixed endpoint
As a GraphOS customer, I could use Persisted Queries and lock down this operation myself in the safelist
I could also disable introspection and ask my client teams to pull the schema with Rover from GraphOS so my API is not being abused and defer the request volume to Apollo's APIs
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I want to allow introspection on my supergraph but I do not want to keep it open for attackers to abuse and run custom or abusive introspection operations. This can lead to cache blowout or coprocessor overload. Instead we should restrict introspection to return a fixed response.
Describe the solution you'd like
There are a few possible outcomes, but as a valid client doing introspection the result I need is the JSON response of an introspection result
/introspection
/sdl
(this would require clients to process but still provides the schema)Hard coded operation
Hard code the introspection query as a saved operation in Router, ideally matching the one returned from graphql-js, and only allow that as a valid introspection option. This can be used then to return the result or from a fixed endpoint
Router config
graphql-js introspection details
SHA-256 Hash of below string
Full Operation String
Describe alternatives you've considered
As a GraphOS customer, I could use Persisted Queries and lock down this operation myself in the safelist
I could also disable introspection and ask my client teams to pull the schema with Rover from GraphOS so my API is not being abused and defer the request volume to Apollo's APIs
The text was updated successfully, but these errors were encountered: