Öffentliche GraphQL-Introspection: warum sie ein Problem ist und wie du sie abschaltest

Schalte Introspection ab, wenn NODE_ENV production ist. Lass sie lokal aktiv, damit dein Team das Schema weiterhin in der Sandbox erkunden kann.

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

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

Yoga bietet ein eigenes Plugin; graphql-http stellt eine Validierungsregel aus graphql-js bereit. Beide stoppen Introspection-Queries, bevor sie ausgeführt werden.

// 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 und Apollo Sandbox sollen Menschen helfen, das Schema zu erkunden — auf einem öffentlichen Produktions-Endpunkt haben sie nichts zu suchen. Schütze sie mit einer Auth-Prüfung oder binde sie im Produktions-Build gar nicht erst ein.

Introspection zu deaktivieren ist eine Härtungsmaßnahme, keine Zugriffskontrolle. Jedes Feld braucht weiterhin eine korrekte Autorisierung auf Resolver-Ebene — sonst kann jeder, der einen Feldnamen errät, es trotzdem aufrufen. Betrachte Introspection als eine Schutzschicht, nicht als die einzige.