Yes, partly. Turning off introspection removes the query that dumps your whole schema, but attackers can still guess field names, and many servers answer a near miss with a hint such as "Did you mean user?". Each hint confirms a real name. Treat introspection as one control, not the whole defence.
What introspection off actually changes
Introspection is the built in feature that lets a client ask a GraphQL server what types and fields exist. The GraphQL project describes it as the system behind the __schema field, and it is what powers developer tools. Switching it off stops that single, convenient map.
It does not change what the server will accept. A client that sends a query with a field name still gets an answer, either data or an error. That error is where the leak continues.
The suggestion leak
OWASP's GraphQL cheat sheet calls out two points. Even with introspection disabled, attackers can guess fields by brute force. And GraphQL has a built in feature that returns a hint when a field name is close to a real one. OWASP gives the example of a request containing usr and a response asking Did you mean "user"?.
Put those together and an attacker can send a list of likely words, read the hints, and rebuild much of the schema over time. It is slower than one introspection call, but it is cheap and easy to script.
OWASP suggests considering turning the suggestion feature off when introspection is off, and notes that not every GraphQL implementation supports doing so. Check your server's documentation for an option, a validation rule, or an error formatter hook.
A quick way to test your own API
Run this against a non production copy first. Send a query with a deliberately misspelled field, then read the error text.
query { usr { id } }
If the error text names a similar real field, suggestions are on. If it only says the field does not exist, you are closer to the goal.
What to do about it
| Control | What it stops | What it does not stop |
|---|---|---|
| Disable introspection | One call dumping the schema | Guessing field names |
| Disable suggestions | Hints that confirm near misses | Blind brute force of names |
| Authorization on every field | Data exposure even when a name is known | Name discovery |
| Query limits and rate limits | Fast, large scale guessing | A patient, slow attacker |
The last two rows matter most. Name discovery is only a problem if knowing a name lets someone read data they should not. Field and object level authorization turns a leaked name into a harmless one. OWASP's guidance is to always check that the requester may read the specific object or property, however the request arrived.
Steps to follow:
- Disable introspection in production and any public environment, unless clients need it by design.
- Disable field suggestions if your server supports it, and test that it worked.
- Return short, generic errors. No stack traces or debug detail.
- Enforce authorization on every field and object, not just at the endpoint.
- Rate limit by cost and operation count, not just by HTTP request.
If your API is meant for outside developers, introspection may be a deliberate feature. In that case, consider allowing it only for authenticated or approved callers, as OWASP suggests.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how an API scan reports exposed behaviour and what it flags for follow up.
Quick check
Is disabling introspection enough on its own?
No. It removes one convenient route to the schema. Guessing and suggestion hints still work unless you also address them, and authorization must hold regardless.
Do all GraphQL servers let you turn off suggestions?
No. OWASP notes that not every implementation supports it. Check your server's documentation, and test with a misspelled field.
Safeguard can scan your APIs and dependencies for known weaknesses, including the GraphQL libraries you run. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
