Skip to content
SysGlass
Security diagnostic

GraphQL Exposure Audit

Enter a URL — a host or an exact GraphQL endpoint — to check whether a GraphQL API is exposing more than it should. Two of the most common GraphQL misconfigurations are leaving schema introspection enabled in production (which hands an attacker the complete map of every type, field and argument in your API) and shipping an interactive GraphiQL or Apollo Playground IDE that anyone can use to explore and run queries. The scanner sends a single read-only introspection query to the conventional GraphQL paths and reports exactly what it finds.

Reviewed by the SysGlass team · Updated July 21, 2026

What it checks

  • Conventional GraphQL endpoints: /graphql, /api/graphql, /v1/graphql, /graphql/v1, /query, /gql (or the exact path you provide)
  • Whether schema introspection is enabled — a query for __schema that returns the type list
  • Whether the endpoint exists but introspection is correctly gated (a GraphQL error envelope)
  • Whether an interactive IDE (GraphiQL, Apollo / GraphQL Playground) is served as a reachable HTML page

How to read the result

  • OK = no GraphQL endpoint was found, or one was found that is properly hardened (introspection disabled and no exposed IDE).
  • Warn = introspection is enabled (the full schema is publicly readable) and/or an interactive IDE is exposed. Both should be turned off in production.
  • The result shows which path responded, how many types introspection returned, and whether an IDE was detected — so the finding is reproducible with a single curl.
  • Only read-only introspection is ever sent — no mutation or subscription is issued against your API.

Frequently asked questions

Is leaving GraphQL introspection on actually a vulnerability?

It is not remote code execution, but it is a recognised production-hardening failure. Introspection exposes your entire schema — every type, field, argument and deprecation — which lets an attacker discover sensitive or under-protected operations far faster than black-box probing. Disabling it in production is standard guidance (and the OWASP GraphQL recommendation).

Is the scan safe and non-destructive?

Yes. It sends a single read-only introspection query ({__schema{...}}) as a normal POST and optionally one GET to look for an IDE page. No mutation or subscription is ever sent, nothing is written, and nothing is brute-forced or executed.

Why does it report a GraphQL endpoint with introspection 'disabled' as OK?

Because that is the hardened, recommended state. When introspection is off, a GraphQL server replies to the introspection query with an error envelope rather than a schema — so we can confirm the endpoint exists yet is correctly locked down, and we report it as OK with no finding.

How do I disable introspection and the IDE?

In Apollo Server set introspection: false for production; in other servers apply the equivalent validation rule that blocks __schema/__type queries. Disable GraphiQL / Playground on production builds or put it behind authentication. Keep both enabled only in development environments.

Related Security tools