Graphql Introspection with Bearer Tokens
How Graphql Introspection Manifests in Bearer Tokens
GraphQL introspection is a powerful feature that allows clients to query the schema of a GraphQL API to discover available types, queries, mutations, and fields. While this is invaluable for development and debugging, it can become a significant security risk when exposed in production environments, especially when combined with Bearer Token authentication.
In Bearer Token-based APIs, introspection can leak sensitive information through several attack vectors. Attackers with valid tokens can enumerate the entire schema, revealing internal data structures, field names, and even business logic that should remain hidden from external users. This becomes particularly dangerous when the introspection query is executed with elevated privileges.
A common manifestation occurs when developers leave the introspection field enabled in production. Consider this vulnerable endpoint:
POST /graphql HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4iLCJpYXQiOjE2MTM5MTQ0MDJ9.xsYx7c1z...
{"query": "{\n __schema {\n types {\n name\n fields {\n name\n }\n }\n }\n}"}This query, when executed with an admin token, reveals the complete schema structure. More sophisticated attacks involve crafting queries that exploit specific field resolvers to extract data. For example:
POST /graphql HTTP/1.1
Authorization: Bearer
{"query": "{\n __type(name: \"User\") {\n fields {\n name\n type {\n name\n kind\n }\n }\n }\n}"} The real danger emerges when introspection combines with BOLA (Broken Object Level Authorization) vulnerabilities. An attacker might discover a users field through introspection, then exploit it:
POST /graphql HTTP/1.1
Authorization: Bearer
{"query": "{\n users {\n id\n email\n role\n sensitiveData\n }\n}"} Without proper authorization checks, this returns all user records, potentially exposing PII, credentials, or business-critical information.
Bearer Tokens-Specific Detection
Detecting GraphQL introspection vulnerabilities in Bearer Token environments requires a multi-faceted approach. The first step is verifying whether introspection is enabled on your GraphQL endpoint. This can be done by sending a simple introspection query without authentication:
curl -X POST https://api.example.com/graphql \
-H "Content-Type: application/json" \
-d '{"query": "{__schema {types {name}}}"}'If this returns schema information, introspection is enabled. The next step is testing with different Bearer Tokens to understand privilege escalation paths. Use tools like graphql-inspector or graphql-playground to systematically explore the schema.
middleBrick's black-box scanning approach is particularly effective here. It automatically tests GraphQL endpoints by sending introspection queries and analyzing responses for sensitive information disclosure. The scanner checks for:
- Enabled introspection queries returning schema information
- Excessive data exposure through GraphQL queries
- Missing authorization checks on sensitive fields
- Rate limiting bypass opportunities
The scanner also tests for common GraphQL-specific vulnerabilities like field injection and batching attacks. For example, it might test:
POST /graphql HTTP/1.1
Authorization: Bearer
{"query": "{\n users {\n id\n email\n role\n __typename\n }\n}"} middleBrick's parallel scanning architecture tests all 12 security categories simultaneously, including GraphQL-specific checks that other scanners miss. The platform provides severity ratings and actionable remediation steps, helping teams prioritize fixes based on actual risk.
Bearer Tokens-Specific Remediation
Remediating GraphQL introspection vulnerabilities in Bearer Token environments requires a layered security approach. The first and most critical step is disabling introspection in production environments. For Apollo Server, this is straightforward:
const { ApolloServer } = require('apollo-server');
const typeDefs = gql`
type Query {\n hello: String\n }\n`;
const resolvers = {\n Query: {\n hello: () => 'Hello world!'\n }\n};
const server = new ApolloServer({\n typeDefs,\n resolvers,\n introspection: process.env.NODE_ENV === 'development'\n});For Express GraphQL, you can disable introspection through configuration:
const express = require('express');
const { graphqlHTTP } = require('express-graphql');
const app = express();
app.use('/graphql', graphqlHTTP({\n schema: myGraphQLSchema,\n graphiql: process.env.NODE_ENV === 'development',\n pretty: process.env.NODE_ENV === 'development',\n introspection: process.env.NODE_ENV === 'development'\n}));Beyond disabling introspection, implement proper authorization at the field level using GraphQL's directive system:
const { ApolloServer, gql } = require('apollo-server');
const typeDefs = gql`
directive @auth(role: String) on FIELD_DEFINITION\n \n type Query {\n publicData: String\n adminData: String @auth(role: \"ADMIN\")\n }\n`;
const resolvers = {\n Query: {\n publicData: () => 'Public info',\n adminData: () => 'Admin only info'\n }\n};
const server = new ApolloServer({\n typeDefs,\n resolvers,\n schemaTransforms: [\n new ApolloServerPluginTransformSchema({\n transformSchema: (schema) => {\n // Add authorization checks\n }\n })\n ]\n});Implement rate limiting specifically for GraphQL endpoints to prevent abuse:
const { createRateLimitDirective } = require('@graphql-tools/rate-limit');
const { rateLimit } = require('express-rate-limit');
const limiter = rateLimit({\n windowMs: 15 * 60 * 1000, // 15 minutes\n max: 100 // limit each IP to 100 requests per windowMs\n});
const rateLimitDirective = createRateLimitDirective({\n identifyContext: true,\n errorMessage: 'Too many requests',\n defaultMax: 100\n});
const typeDefs = gql`
directive @rateLimit(limit: Int, window: String) on FIELD_DEFINITION\n \n type Query {\n publicData: String @rateLimit(limit: 50, window: \"15m\")\n }\n`;Finally, implement comprehensive logging and monitoring for GraphQL queries, especially those using introspection or accessing sensitive fields. This helps detect and respond to potential attacks in real-time.