Yes, for public or production endpoints, unless a known set of consumers needs it. OWASP's GraphQL guidance says to disable introspection in production or publicly accessible environments, and to filter access by role if some consumers need it. Turning it off reduces exposure, but it does not replace authorization or query limits.
Definitions
Introspection is a GraphQL feature that lets a client ask the server to describe its own schema: types, fields, queries and mutations. Developer tools such as schema explorers use it. GraphiQL is one such in browser explorer.
What it exposes
A full schema is a map of your API. It can reveal fields and operations that the public web app never calls, including admin mutations and internal object types. That makes it easier to find targets for the flaws OWASP lists, such as broken object level or function level authorization.
What the guidance recommends
| Control | OWASP GraphQL cheat sheet guidance |
|---|---|
| Introspection | Disable in production or publicly accessible environments |
| Schema explorers | Disable GraphiQL and similar tools in production |
| Field suggestions | Turn off "Did you mean" hints when introspection is off, since they can reveal field names |
| Depth and amount | Limit both, since they are unlimited by default |
| Batching | Cap operations per batch, disable it for login and OTP checks |
| Authorization | Check access on each object and field, not just the ID |
| Timeouts | Apply application level timeouts for queries and resolvers |
What turning it off does not do
The cheat sheet is candid that attackers can still brute force field names, so disabling introspection reduces exposure rather than eliminating it. Treat it as a speed bump. The real protections are the checks in the table: authorization on every object and field, limits on depth and cost, and batching rules.
OWASP's authentication guidance gives a concrete example of why batching matters. A login mutation limited to three attempts a minute can be bypassed when many login mutations arrive in one batched request.
A rollout plan
- Check which clients actually use introspection in production, by looking at logs.
- Move development tooling to a non production environment.
- Disable introspection and explorers in production, and verify with a test query.
- Disable field suggestions.
- Add depth, amount and batching limits.
- Add authorization tests for objects and fields.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a dynamic scan probes a running app for exposed behaviour.
Quick check
Will disabling introspection break my own front end?
Usually not, since production clients ship with their queries. Tools and codegen that fetch the schema at runtime may break, so check first.
Is a private GraphQL API exempt?
No. The cheat sheet says disabling is the simplest option for internal APIs too.
Safeguard's free scan at gold.safeguard.sh/scan checks the dependency side of your GraphQL service.
Sources
Last reviewed: 19 October 2026.
