In REST traffic, endpoint, method and path usually describe what a request does. In GraphQL, that information lives mostly in the body. The same `/graphql` endpoint can carry reads, writes, nested queries, introspection, fragments and variable-driven operations. A security layer that only checks URL and method cannot see what GraphQL is actually doing.
When GraphQL introspection remains open in production, the application schema can leak. An attacker who learns which types, fields and relationships exist can craft far more targeted queries. This may not be direct data exfiltration, but it is a serious information disclosure that maps the attack surface.
Nested queries and fragments create a different risk. Excessively deep nested queries can impose heavy processing load on the backend with a single HTTP request. Standard rate limiting counts requests — it does not see the cost of a single request. In GraphQL, DoS risk usually comes from query structure, not request volume.
Query batching produces a similar gap. When multiple queries are sent in one body, the traffic looks like a single HTTP request from the outside, but multiple operations may run on the inside. This undermines classic rate-limit and endpoint-based security controls.
TR7 GraphQL Deep Inspection examines GraphQL traffic with pattern-based WAAP rules: introspection, nested-depth DoS and query batching behaviors are detected across query, raw, json and form scopes and tied to production policies.
TR7 addresses GraphQL security not by claiming schema awareness, but by bringing the most common production GraphQL abuse patterns into the WAAP signature engine.
TR7 catches introspection indicators such as `__schema`, `__type`, `IntrospectionQuery` and `fragment FullType` using regex-based rules. These rules can run in block mode in production and in monitor mode or at a lower score in staging.
Excessively nested GraphQL queries can generate heavy processing load with a single request. The TR7 50101 rule family detects deep `{ ... { ... } }` chains at the pattern level and includes them in the WAAP decision with a high score.
Sending multiple queries in one body can undermine classic rate-limit logic. TR7 rule 50102 detects batch query patterns and enables tying that behavior to a log, score or block decision.
A GraphQL query may be carried not only in the raw body but also in JSON, form or query string fields. TR7 rules run across query, raw, json and form scopes, bringing different client implementations under the same WAAP policy.
GraphQL Deep Inspection manages GraphQL-specific risks with signature-based WAAP rules, scope selection and endpoint hardening controls.
Rule 50100 targets patterns commonly used in GraphQL introspection: `__schema`, `__type`, `IntrospectionQuery` and `fragment FullType`. The default risk level is positioned as a medium-strength signal and can be evaluated at score 4. On endpoints where introspection must be closed in production, this rule can run in block or monitor mode. Schema discovery attempts become visible in the WAAP event stream.
Rule 50101 detects excessively nested GraphQL queries at the pattern level. Deep `{` chains and heavily nested structures can cause a single request to impose high processing cost on the backend. This rule can be evaluated at score 6 as a stronger attack signal. The goal is not to perform schema-aware complexity calculation — it is to catch dangerous nested query patterns early.
Rule 50102 detects batch patterns where multiple queries are sent in a single body. Because query batching may be legitimate for some clients, the rule's state and score values should be tuned to the application's behavior. Starting in monitor mode and clarifying with real traffic observation is the right approach. Once abuse is confirmed, the rule can be moved to a blocking policy.
Alongside TR7 enriched rules, waf_db contains GraphQL variants such as the 50100, 50101 and 21360+ families. These variants cover alternative spellings such as `__schema {`, `__type`, `__typename` and nested mutation patterns. This builds a broader signature surface for introspection and nested query behaviors without relying on a single regex. Operators can override the state and score of these rules per service.
GraphQL queries do not always arrive in the same format. Some clients send `query`, `variables` and `operationName` fields inside a JSON body; others may use raw body or form fields. TR7 rules run across query, raw, json and form scopes, bringing these different transport formats into the inspection coverage. This reduces the mistake of trusting only one body format on GraphQL endpoints.
GraphQL controls can be applied to both api_endpoint and web_application targets. The same WAAP rule model can be managed with different state, score or scope values depending on service type. For example, introspection can remain in monitor mode on an internal test endpoint while being blocked on a public production endpoint. This flexibility allows a single rule set to be adapted to different environment policies.
Controls can be defined for the `/graphql` endpoint such as allowing only the POST method, restricting expected JSON keys to `query`, `variables` and `operationName`, or applying a body size limit. These controls do not replace GraphQL signatures — they are a positive security layer that complements them. Unexpected methods or unexpected JSON fields can be rejected at an early stage, making endpoint behavior more predictable.
If GraphQL traffic includes application-specific mutation patterns, field names or risky operation names, they can be added as custom WAAP rules. For example, a specific `mutation` keyword or sensitive operation name appearing in the body can be assigned a higher score. These custom rules participate in the main WAAP scoring system and are visible in the log and SIEM stream. Even without schema-aware field inspection, application-specific risks can be caught with pattern-based rules.
GraphQL Deep Inspection is signature-based in its current real capabilities — operation parsing, complexity calculation and schema-aware field WAAP claims are out of scope for this page.
GraphQL controls work with a regex and scope-based pattern detection approach. Operation type differentiation, a real depth counter or query complexity score calculation are not part of this model. This distinction is especially important for accurate positioning.
Rules 50100, 50101, 50102 and waf_db variants can be set to enabled, monitor or disabled depending on service need. Score values can also be tuned to the application's false-positive tolerance. The right rollout model for production GraphQL endpoints is to start in monitor mode and move to blocking after real traffic observation.
Method whitelist, JSON key allow-list and body size limit can be applied on GraphQL endpoints. These controls ensure the request shape conforms to the expected contract alongside signature detection. On public APIs in particular, accepting only the expected format on the `/graphql` endpoint narrows the attack surface.
Per-operation rate-limiting is not applied at the GraphQL parser level. There is no claim of semantically parsing the number of operations inside a single body and applying a separate limit to each. The query batching pattern can be caught as a signature and used alongside general rate-limit policies.
There is no dedicated support for persisted queries within this capability. GraphQL patterns visible in the request are inspected with WAAP signatures. Resolving a query from its hash and verifying it against schema or registered operation data is not claimed on this page.
Native inspection at the level of a specific GraphQL schema field — for example `User.email` — is not performed. Rules work with a pattern-matching approach against the body. If there are field-specific requirements, they should be addressed in a limited and careful way with a custom regex rule.
A security team can allow introspection in staging while running rule 50100 in block mode on the production endpoint. Schema discovery attempts are logged, scored and blocked per policy.
Excessively nested fragments or query structures can impose high processing cost on the backend. Rule 50101 catches these patterns at score 6, providing a strong signal for the WAAP blocking decision.
When many queries are attempted in a single request to a mobile client endpoint, rule 50102 detects the batch pattern. The operations team can observe the behavior in monitor mode first and switch to enabled mode once abuse is confirmed.
An API team can allow only the POST method and the `query`, `variables` and `operationName` JSON fields on the `/graphql` endpoint. Unexpected methods or fields are rejected before they reach the application, narrowing endpoint behavior.
Make introspection, nested DoS and query batching risks visible and manageable in production. Let's walk through a live setup on your own services.