GraphQL gateways security

GraphQL gateways introduce a distinct threat model compared to REST endpoints. The gateway accepts a query language syntax, resolves multiple underlying services, and exposes a single ingress point. This aggregation amplifies risks around introspection, schema exposure, and complex nested queries that can strain parsers and resolvers.

Black-box scanning interacts with the gateway as an opaque endpoint, focusing on what the API surface reveals without insight into implementation. The scanner submits queries and observes responses, tracking how the gateway handles malformed inputs, authorization boundaries, and data exposure across stitched services.

Because the gateway mediates requests, misconfigurations such as overly permissive query depth, excessive field access, or weak field-level authorization can propagate to downstream services. Mapping findings to OWASP API Top 10 helps contextual这些问题 in the context of common API risks rather than assuming the gateway enforces fine-grained controls inherently.

The scanner performs read-only interactions, avoiding intrusive payloads. It probes introspection to assess schema exposure and observes how the gateway handles queries that reference types and fields across federated services.

• Introspection and schema exposure — whether the gateway allows full introspection in production and how it handles partial or filtered schema responses.
• Query depth and complexity — detection of nested queries that can cause parser exhaustion or denial of service.
• Field-level authorization checks — verifying whether the gateway enforces selection and access controls for sensitive fields across federated sources.
• Input validation and injection surface — testing for injection-like patterns in arguments and directives, focusing on how the gateway parses and forwards them.
• Rate limiting and resource consumption — observing gateway-level headers and response sizes for unbounded arrays or unhandled large payloads.
• Data exposure and PII leakage — identifying patterns that reveal emails, card-like values, or other sensitive data in responses.

Authenticated scanning for GraphQL gateways supports Bearer, API key, Basic auth, and Cookie methods. Domain verification ensures that only the domain owner can submit credentials for scans that rely on authenticated contexts.

The scanner cross-references the OpenAPI or GraphQL schema definitions against runtime observations to highlight undefined security schemes, deprecated operations, and missing pagination controls. It surfaces findings relevant to authorization boundaries, helping you validate controls described in SOC 2 Type II and PCI-DSS 4.0 without asserting certification or compliance guarantees.

Header allowlists restrict forwarded headers to Authorization, X-API-Key, Cookie, and X-Custom-* to reduce noise and limit credential leakage during testing. The scanner does not modify, patch, or block traffic; it reports observed behaviors and guidance.

Pro tier continuous monitoring performs scheduled rescans at intervals of six hours, daily, weekly, or monthly. It detects diffs between scans, highlighting new findings, resolved findings, and score drift specific to the gateway behavior observed.

Email alerts are rate-limited to one per hour per API to avoid notification storms. HMAC-SHA256 signed webhooks provide automated alerts with auto-disable after five consecutive failures, enabling integration with existing incident response workflows.

For CI/CD, the GitHub Action acts as a gate that fails the build when the score drops below a configured threshold. The CLI allows on-demand scans via middlebrick scan <url>, producing JSON or text output for pipeline consumption. The MCP Server enables scanning from AI coding assistants such as Claude and Cursor.

The scanner does not fix, patch, block, or remediate issues. It detects and reports with guidance, leaving implementation decisions to your team. GraphQL-specific business logic vulnerabilities, such as misuse of federation directives or resolver-level logic flaws, require human expertise aligned with your domain.

The scanner does not perform active SQL injection or command injection tests, as those fall outside read-only, black-box scope. Blind SSRF and out-of-band infrastructure checks are also out of scope.

Customer scan data is deletable on demand and purged within 30 days of cancellation. It is never sold and is not used for model training. For high-stakes audits, treat the scanner as an evidence source rather than a replacement for a human pentester.