GraphQL's flexibility is exactly what conventional REST-focused tools miss. 42Crunch applies the same contract-first security model to GraphQL schemas that it already applies to OpenAPI — static analysis, live testing, and automated enforcement.
A single flexible endpoint, client-shaped queries, and nested resolvers give GraphQL real power — and a distinct set of vulnerabilities that tools built to look at REST routes and HTTP verbs simply don't check for. Schema exposure, resource-exhaustion attacks through deeply nested or expensive queries, unauthorized data access through under-guarded fields, unprotected mutations, and gaps at the edges of federated services all live outside what a conventional scanner is looking for.
Introspection left enabled hands an attacker your entire data graph as a map, including fields and mutations nobody meant to publish.
Deeply nested or high-cost queries can turn a single request into a denial-of-service — GraphQL lets a client shape a query REST never allowed.
A field-level authorization gap doesn't show up in a route list — it shows up when the wrong field returns data it shouldn't.
Mutations carry the same write-path risk as a REST POST or PUT, but rarely get the same scrutiny in schema review.
A supergraph is only as secure as its least-audited subgraph — federation multiplies the attack surface without multiplying the review.
42Crunch evaluates the GraphQL SDL itself — introspection and data-exposure risk, missing authentication on queries and mutations, unconstrained strings and custom scalars, absent input validation, query-cost and list-size coverage, and Apollo Federation subgraph security. Every finding is scored and mapped, the same as an OpenAPI contract audit, before a single request ever reaches a running server.
Contract-aware dynamic testing checks authentication and authorization weaknesses, nested-operation and query-complexity abuse, mutation security failures, invalid and malicious field inputs, and federation and subgraph security issues — validating that the live service behaves the way the schema claims it does, not just that the schema reads well.
A dedicated GraphQL Security Quality Gate compares audit and scan results against an approved threshold, and fails the build or blocks the release when a schema or a running API doesn't meet it — the same enforcement model 42Crunch already applies to REST, extended down to the query layer. Once a contract is validated, that same definition drives precise runtime enforcement for as long as the API is live.
Not on its own. A WAF operates at the HTTP and network level, with no visibility into GraphQL specifics — schema structure, resolver relationships, field-level access, or how a federated graph is composed. Catching what actually goes wrong in GraphQL takes schema-aware analysis and testing, not just traffic inspection.
No. The static SDL Audit reads the schema definition directly, without ever calling a live endpoint. Only the dynamic Scan connects to a running API — typically staging, not production — so introspection can stay switched off where it matters most.
Yes — query-cost and list-size coverage is part of the static audit, and the dynamic scan specifically tests nested-operation and query-complexity abuse against the running API, so an expensive query gets flagged before it turns into a denial-of-service.
Yes, including both subgraph and supergraph assessment. Because a composed graph can hide a subgraph's own access controls, 42Crunch reconstructs subgraph ownership and validation context rather than judging the graph only as assembled.
Yes — both are organized, audited, tested, and governed inside the same platform, so a mixed REST-and-GraphQL portfolio runs under one consistent security policy instead of two disconnected tools.
Through dedicated GraphQL Security Quality Gates. Audit and scan results are compared against an approved threshold, and a build or release can be failed automatically when a schema or a running API falls short.
Yes — every finding links out to a GraphQL-specific entry in the Knowledge Database, with the relevant location in the SDL, an explanation of the risk, a realistic attack scenario, and the recommended fix.
Yes — validation directives used with Spring GraphQL and graphql-java, including @Min, @Max, @Size, @Pattern, and @NotEmpty, are recognized rather than treated as opaque schema decoration.
No. It's a full lifecycle: static SDL Audit, dynamic Scan against the running API, CI/CD Security Quality Gates, and contract-driven runtime protection once the API is live.
Point 42Crunch at a GraphQL schema or a live endpoint and get a scored audit back — no agent install, no commitment required.