GraphQL gateway audit

Run the GraphQL gateway audit check

What middleBrick covers

  • Black-box GraphQL endpoint risk grading A–F
  • Introspection and schema validation
  • Authentication and authorization surface checks
  • Sensitive data and error exposure detection
  • Query depth and complexity surface analysis
  • CI/CD and workflow integration options

What is a GraphQL gateway audit

A GraphQL gateway audit validates the security posture of a federated GraphQL architecture, where a gateway composes multiple subgraphs and exposes a unified query surface. The audit checks the gateway configuration, subgraph contracts, query complexity controls, and runtime exposure to confirm that authentication, authorization, and data exposure risks are bounded. Teams should treat this as part of continuous API risk management rather than a one-time checklist.

Common gaps when skipping a gateway audit

Without a structured audit, federated GraphQL setups commonly expose introspection and debug queries in production, allow unauthenticated queries, and leak subgraph-specific errors that reveal stack traces or internal paths. Over-permissive query planning can enable large nested requests that degrade backend performance, while inconsistent authorization rules across subgraphs allow horizontal privilege escalation across services.

  • Introspection and schema discovery left enabled in production
  • Missing query cost or depth limits leading to resource exhaustion
  • Inconsistent auth enforcement across federated subgraphs
  • Error messages exposing internal hostnames or file paths
  • Lack of versioning controls for the gateway schema

Workflow for a secure GraphQL gateway implementation

Implement a repeatable workflow that combines design reviews, automated scanning, and runtime controls. Define a clear schema ownership model, enforce strict type and field permissions, and validate that the gateway applies consistent security policies across all subgraphs. Include automated tests for query depth, complexity, and injection edge cases before promotion to production.

curl -s -X POST https://gateway.example.com/graphql \
  -H "Content-Type: application/json" \
  -d '{ "query": "{ __typename } { users { id name } }" }' | jq .

How middleBrick covers GraphQL gateway risk

middleBrick scans the public GraphQL endpoint as a black-box service, focusing on the gateway behavior without requiring code or infrastructure access. The scanner resolves the schema via introspection, validates security headers, checks for sensitive data exposure in error responses, and probes for common federation misconfigurations such as IDOR patterns across subgraphs.

It maps findings to OWASP API Top 10 (2023) and supports audit evidence collection for SOC 2 Type II and PCI-DSS 4.0 controls. The scan runs in under a minute, returns a risk grade from A to F with prioritized remediation guidance, and provides JSON output for integration into CI/CD pipelines.

Scan options and integration guidance

Use the CLI for ad hoc checks during design and pre-production phases: middlebrick scan https://api.example.com/graphql. For federated setups, include representative queries in the body if your gateway requires POST for introspection. Enable authenticated scanning when you need to validate protections behind APIs protected by Bearer, API key, Basic, or cookie-based credentials. Pro tier continuous monitoring can schedule rescans and email alerts to track score drift as the federation evolves.

Review the dashboard to track remediation progress, export compliance PDFs for PCI-DSS 4.0 evidence, and integrate the GitHub Action to block merges when the score drops below your defined threshold.

Run this check on your API See all use cases

Frequently Asked Questions

Does this replace a penetration test for GraphQL services?
No. The scanner detects common misconfigurations and schema-level risks but does not identify business logic flaws that require domain context. Use it as a complement to human-led assessments.
Can authenticated scans validate role-based access controls across subgraphs?
Authenticated scans verify that authentication is required and that credentials are handled consistently. They surface exposed fields and over-permissive endpoints, but validation of fine-grained role-based rules should include manual testing aligned to your domain model.
How are scan results mapped to compliance frameworks?
Findings map directly to OWASP API Top 10 (2023) and support audit evidence for SOC 2 Type II and PCI-DSS 4.0. For other regulations, the results help you prepare evidence and align with security controls described in the relevant frameworks.
Does scanning impact production performance or data?
Scans use read-only methods and avoid destructive payloads. They are designed to minimize load, but you should coordinate scheduling with operations to avoid peak traffic windows.
Can the scanner analyze gateway plugins or custom federation logic?
The scanner evaluates runtime behavior and schema exposure. It does not inspect gateway plugin code or custom resolver implementations; use code reviews and internal security testing for those components.