GraphQL Introspection Exposure Checker
Sends one real GraphQL introspection query to an endpoint URL you choose and reports whether introspection is enabled -- exposing every query, mutation, and subscription field name, and every named type, including ones no client ever links to. This is the reconnaissance step OWASP's API Security guidance names as a reason to disable introspection in production. Only point it at a system you own or are authorised to test.
1. Check an endpoint
Enter an endpoint URL and click Check. This tries the request directly from your browser first.
2. Or run the CLI and paste its output
If your browser could not read a response (commonly a CORS policy that doesn't allow this page's origin), the request is not subject to that restriction from a plain Node script:
node check.mjs https://api.example.com/graphql --jsonGet check.mjs, probe.mjs, and analyze.mjs from the repo — plain Node, nothing to install. It only ever talks to the URL you pass; nothing goes through this site.
Report
| Root type | Field count | Field names |
|---|
Common questions
What is GraphQL introspection and why does leaving it enabled matter?
Introspection is a set of built-in GraphQL meta-fields (__schema, __type) that let any caller ask the API to describe its own schema -- every query, mutation, subscription, type, and field name. It is essential during development, but on a production endpoint it hands an unauthenticated caller a complete map of the API's surface, including mutations and fields no real client ever links to. OWASP's API Security guidance and GraphQL's own production-hardening documentation both name disabling introspection in production as standard practice.
Why does the browser sometimes need a CLI instead of just checking the URL I type in?
The introspection query itself needs no special browser-forbidden header -- it's an ordinary POST with a JSON body -- so this page tries it directly first. Whether that succeeds depends entirely on the target's own CORS policy: some public GraphQL APIs allow requests from any origin (they're built to be called from arbitrary frontends), and for those the check runs entirely in your browser. A target with a stricter CORS policy will block the browser from reading the response even though the request reached the server -- the browser hides the response rather than reporting an error. The CLI has no such restriction, because CORS is enforced by browsers, not by Node's fetch, so it always gets a real answer.
Is it safe to run this against an endpoint?
It sends exactly one ordinary POST request carrying a read-only introspection query -- GraphQL's introspection meta-fields cannot mutate anything. It does nothing a GraphQL client wouldn't also do by querying the endpoint directly. Only point it at a system you own or are authorised to test, the same rule that applies to any request tool aimed at someone else's server.
Does a clean report mean the API has no other security issues?
No. This checks exactly one thing -- whether an unauthenticated introspection query succeeds -- from one request. It is not a full security assessment, does not test authenticated behaviour, field-level authorization, query depth/complexity limits, or batching/aliasing abuse, and a sensitive-sounding field name is a hint to review by hand, not proof of a missing access control. Treat a clean report as evidence about introspection specifically.
More background: why production GraphQL APIs disable introspection, and what it actually protects against.
See this checker vs. checking introspection by hand -- why testing from the API's own GraphiQL UI understates the risk, and why the mutation surface is easy to miss on a skim.