GraphQL Introspection Lab: Find the Hidden Admin Query

This article describes a GraphQL security lab that teaches how introspection queries can expose hidden admin functionality in APIs. The core problem is that GraphQL servers often leave introspection enabled in production, revealing the complete API schema including undocumented and admin-only fields that lack authorization checks. This matters because attackers can use introspection as a reconnaissance tool to discover and exploit sensitive operations that were never meant to be publicly accessible.

• Introspection reveals complete API surfaceGraphQL's built-in introspection feature allows clients to query a server for its complete schema—all types, queries, mutations, and fields. When enabled in production, this exposes every endpoint including undocumented or admin-only ones that were never linked in the user interface. The server answers introspection queries before any business logic runs, meaning the entire schema is revealed regardless of who is asking.
• Security through obscurity fails completelyThe lab demonstrates that admin queries protected only by not being linked in the UI are trivially discoverable via introspection. Once exposed, if the field lacks an authorization check, calling it requires only knowing its arguments and return fields—both of which introspection provides. This illustrates the principle that obscurity is not access control.
• Attack requires only standard introspection queriesAn attacker sends the standard __schema introspection query to the endpoint, scans the returned fields for administrative or undocumented operations, determines the expected arguments and return fields from the schema map, then calls the hidden query directly to read sensitive data. The entire attack is straightforward enumeration followed by direct invocation.
• Introspection is enabled by default in many frameworksThe article notes that introspection left enabled in production is one of the most common GraphQL findings because many frameworks enable it by default. When combined with missing field-level authorization, this configuration regularly exposes admin operations and sensitive data in real-world bug-bounty reports.
• Real-world classification under OWASP Top 10The article categorizes this vulnerability under OWASP A05 (Security Misconfiguration) when introspection is enabled, and under A01 (Broken Access Control) when sensitive fields lack authorization checks. This dual classification reflects both the configuration error and the underlying authorization failure.
• Defense requires multiple complementary controlsThe article recommends disabling or restricting introspection to authenticated internal use in production, implementing authorization checks on every field and mutation rather than relying on fields being undocumented, applying query depth and cost limits to prevent abuse, and reviewing the schema for fields that should not be reachable by ordinary users. No single control is sufficient—disabling introspection alone does not fix fields that can still be guessed.
• Introspection queries are reconnaissance starting pointThe article advises that on authorized GraphQL testing engagements, running an introspection query first should be the standard approach because the schema serves as a complete map of the API. Hidden mutations and admin queries discovered this way represent the fastest route to high-impact security findings.

Bottom line: Introspection in GraphQL production environments is a critical reconnaissance vulnerability because it exposes the complete API schema including hidden admin operations. Defense requires both disabling introspection in production and implementing proper authorization checks on every sensitive field—neither control alone is sufficient.