Introspection GraphQL publique : pourquoi c'est un problème et comment la désactiver

Désactivez l'introspection lorsque NODE_ENV vaut production. Laissez-la active en local pour que votre équipe puisse continuer à explorer le schéma dans le Sandbox.

import { ApolloServer } from "@apollo/server";

const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== "production",
});

Yoga propose un plugin dédié ; graphql-http expose une règle de validation issue de graphql-js. Les deux bloquent les requêtes d'introspection avant leur exécution.

// GraphQL Yoga
import { createYoga } from "graphql-yoga";
import { useDisableIntrospection } from "@graphql-yoga/plugin-disable-introspection";

export const yoga = createYoga({
  schema,
  plugins: process.env.NODE_ENV === "production" ? [useDisableIntrospection()] : [],
});

// graphql-http (or express-graphql)
import { NoSchemaIntrospectionCustomRule } from "graphql";

const validationRules = process.env.NODE_ENV === "production"
  ? [NoSchemaIntrospectionCustomRule]
  : [];

GraphiQL, Playground et Apollo Sandbox servent à aider des humains à explorer le schéma — ils n'ont pas leur place sur un endpoint de production public. Protégez-les par une vérification d'authentification ou ne les montez pas du tout dans le build de production.

Désactiver l'introspection est une mesure de durcissement, pas un contrôle d'accès. Chaque champ a toujours besoin d'une autorisation correcte au niveau du resolver — sinon, quiconque devine un nom de champ peut encore l'appeler. Considérez l'introspection comme une couche de défense parmi d'autres, pas comme la seule.