Skip to content

GraphQL Tracing Enabled

Description

GraphQL Tracing is a feature that, when enabled, provides detailed timing information about the execution of a GraphQL query. While useful for debugging and performance optimization, it can potentially leak sensitive information about the server's internal workings when left enabled in a production environment.

When tracing is enabled, the GraphQL server includes an extensions field in the response, containing a tracing object. This object includes detailed information about the execution of each resolver in the query, including start times, end times, and durations.

Example of a response with tracing enabled:

{
  "data": {
    "field1": "value1",
    "field2": "value2"
  },
  "extensions": {
    "tracing": {
      "version": 1,
      "startTime": "2023-09-17T10:00:00.000Z",
      "endTime": "2023-09-17T10:00:00.050Z",
      "duration": 50000000,
      "execution": {
        "resolvers": [
          {
            "path": ["field1"],
            "parentType": "Query",
            "fieldName": "field1",
            "returnType": "String",
            "startOffset": 1000000,
            "duration": 2000000
          },
          {
            "path": ["field2"],
            "parentType": "Query",
            "fieldName": "field2",
            "returnType": "String",
            "startOffset": 3000000,
            "duration": 1000000
          }
        ]
      }
    }
  }
}

Security Impact of GraphQL Tracing: - Information Disclosure: Tracing data can reveal internal details about the GraphQL server's structure and performance, which could be leveraged by attackers to plan more targeted attacks. - Performance Overhead: Enabling tracing in production can introduce unnecessary performance overhead, potentially impacting the server's ability to handle high loads. - Data Privacy Concerns: In some cases, tracing data might include sensitive information that shouldn't be exposed to clients.

Recommendation

GraphQL Tracing Recommendations

To mitigate the risks associated with GraphQL Tracing, consider the following recommendations:

  1. Understand Tracing Implementation: GraphQL tracing is typically implemented using plugins and often sends data to separate tracing servers (e.g., Jaeger) rather than exposing it directly in GraphQL responses.

  2. Control Tracing in Production: Use environment variables or configuration settings to easily enable or disable tracing based on the environment.

  3. Implement Access Controls: If tracing is enabled in production, implement strict access controls on the tracing server (e.g., Jaeger) to ensure only authorized personnel can access the tracing data.

  4. Sanitize Tracing Data: Ensure that sensitive information is not included in the traced data before it's sent to the tracing server.

  5. Use Secure APM Tools: Consider using dedicated Application Performance Monitoring (APM) tools that provide secure and comprehensive monitoring capabilities for production environments.

Example of implementing tracing with environment-based control in Apollo Server:

const { ApolloServer } = require('apollo-server');
const { ApolloServerPluginInlineTrace } = require('apollo-server-core');

const isProduction = process.env.NODE_ENV === 'production';
const plugins = [];

if (!isProduction) {
  plugins.push(ApolloServerPluginInlineTrace({
    rewriteError: (err) => {
      // Optionally rewrite errors before sending to the tracing service
      return err;
    },
  }));
}

const server = new ApolloServer({
  typeDefs,
  resolvers,
  plugins,
});

This setup allows you to easily control tracing based on the environment, ensuring it's not accidentally enabled in production.

For other GraphQL server implementations, consult the specific documentation on how to implement and control tracing securely.

Standards

  • PCI_STANDARDS:
    • REQ_2_2
    • REQ_6_2
    • REQ_6_3
    • REQ_6_5
    • REQ_11_3
  • OWASP_MASVS_L2:
    • MSTG_ARCH_9
  • OWASP_ASVS_L3:
    • V1_4_4
  • SOC2_CONTROLS:
    • CC_6_1
    • CC_6_7
    • CC_7_1