1. Introduction
GraphQL Introspection Enabled allows attackers to query detailed information about a GraphQL API’s schema and capabilities. This can reveal sensitive data, internal structures, and potential attack vectors. It typically affects applications using GraphQL APIs without proper access controls. A successful exploit could lead to data breaches or further attacks on the application. Confidentiality, integrity, and availability may be impacted.
2. Technical Explanation
GraphQL introspection is a feature that allows clients to query the schema of a GraphQL API. When enabled without restrictions, anyone can request this information. An attacker could use this to understand the API’s structure and identify potential vulnerabilities. The scanner detected that GraphQL introspection is enabled on one or more endpoints.
- Root cause: Lack of access controls on GraphQL introspection queries.
- Exploit mechanism: An attacker sends a query to retrieve schema information, potentially revealing sensitive data types, fields, and relationships. For example, an attacker could use a tool like GraphiQL or Insomnia to send an introspection query against the API endpoint.
- Scope: Applications using GraphQL servers with introspection enabled without authentication or authorization.
3. Detection and Assessment
Confirming whether your system is vulnerable involves checking if introspection queries are allowed. Use a quick check followed by a thorough method to verify access controls.
- Quick checks: Access the GraphQL endpoint in a browser or using a tool like curl and attempt an introspection query.
- Scanning: Nessus, OpenVAS, and other vulnerability scanners may have plugins for detecting enabled GraphQL introspection. These are examples only.
- Logs and evidence: Check application logs for requests containing “__schema” or similar introspection keywords. Exact paths vary depending on the logging configuration.
curl -X POST "https://your-graphql-endpoint" -H "Content-Type: application/json" -d '{"query": "{ __schema { types { name } }}"}'4. Solution / Remediation Steps
Fixing this issue involves restricting access to GraphQL introspection or disabling it entirely. Follow these steps carefully to avoid disrupting API functionality.
4.1 Preparation
- Services: Stop the application service if necessary for configuration updates.
- Rollback: Revert any configuration changes if issues arise during implementation.
4.2 Implementation
- Step 2: If authentication is not feasible, disable introspection entirely in the server’s configuration file.
- Step 3: Restart the application service for changes to take effect.
4.3 Config or Code Example
Before
# Apollo Server configuration (example)
const server = new ApolloServer({
schema,
});After
# Apollo Server configuration with introspection disabled (example)
const server = new ApolloServer({
schema,
introspection: false,
});4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue and similar vulnerabilities. These include least privilege access control and secure configuration management.
- Practice 1: Least privilege – restrict access to sensitive API features, like introspection, to authorized users only.
- Practice 2: Secure defaults – configure GraphQL servers with restrictive settings by default, requiring explicit enabling of features like introspection.
4.5 Automation (Optional)
If using Infrastructure as Code (IaC), you can automate the configuration of introspection settings.
# Terraform example (example only - syntax varies by provider)
resource "aws_appsync_graphql_api" "example" {
name = "my-graphql-api"
authentication_type = "API_KEY"
additional_authorization_modes {
content_type = "application/json"
authorization_mode = "IAM"
}
# Disable introspection (syntax varies by provider)
introspection = false
}5. Verification / Validation
- Post-fix check: Attempt an introspection query again using curl or a similar tool. Expect a 401 Unauthorized error if authentication is enabled, or a failure to retrieve the schema if it’s disabled.
- Re-test: Re-run the scanner used in detection to confirm that the vulnerability is no longer reported.
- Monitoring: Monitor application logs for failed introspection attempts, which could indicate unauthorized access attempts.
curl -X POST "https://your-graphql-endpoint" -H "Content-Type: application/json" -d '{"query": "{ __schema { types { name } }}"}'6. Preventive Measures and Monitoring
Preventative measures include updating security baselines and incorporating checks into CI/CD pipelines. Regular patch reviews are also important.
- Baselines: Update your application security baseline to require restricted access to GraphQL introspection by default.
- Asset and patch process: Review configuration changes regularly to ensure that security settings are maintained.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 1: Disabling introspection can make API debugging more difficult.
- Risk or side effect 2: Some client libraries or tools may rely on introspection to discover schema information.
- Roll back: Revert the configuration changes made in step 4.2 and restart the application service.
8. References and Resources
- Vendor advisory or bulletin: https://www.apollographql.com/blog/graphql/security/why-you-should-disable-graphql-introspection-in-production/
- NVD or CVE entry: Not applicable for this general misconfiguration.
- Product or platform documentation relevant to the fix: https://graphql.org/learn/introspection/