No tráfego REST, endpoint, método e path geralmente descrevem o que uma requisição faz. No GraphQL, essa informação fica principalmente no corpo. O mesmo endpoint `/graphql` pode carregar leituras, escritas, queries aninhadas, introspecção, fragmentos e operações orientadas por variáveis. Uma camada de segurança que verifica apenas URL e método não consegue ver o que o GraphQL está realmente fazendo.
Quando a introspecção GraphQL permanece aberta em produção, o schema da aplicação pode vazar. Um atacante que descobre quais tipos, campos e relacionamentos existem pode criar queries muito mais direcionadas. Isso pode não ser exfiltração direta de dados, mas é uma divulgação séria de informações que mapeia a superfície de ataque.
Queries aninhadas e fragmentos criam um risco diferente. Queries aninhadas excessivamente profundas podem impor carga de processamento pesada ao backend com uma única requisição HTTP. O rate limiting padrão conta requisições — ele não vê o custo de uma única requisição. No GraphQL, o risco de DoS geralmente vem da estrutura da query, não do volume de requisições.
O query batching produz uma lacuna semelhante. Quando múltiplas queries são enviadas em um único corpo, o tráfego parece uma única requisição HTTP por fora, mas múltiplas operações podem rodar por dentro. Isso prejudica os controles de segurança clássicos baseados em rate limit e endpoint.
TR7 GraphQL Deep Inspection examina o tráfego GraphQL com regras WAAP baseadas em padrões: introspecção, DoS de profundidade aninhada e comportamentos de query batching são detectados nos escopos query, raw, json e form e vinculados a políticas de produção.
TR7 aborda a segurança GraphQL não reivindicando consciência de schema, mas trazendo os padrões de abuso GraphQL mais comuns em produção para o motor de assinaturas WAAP.
TR7 captura indicadores de introspecção como `__schema`, `__type`, `IntrospectionQuery` e `fragment FullType` usando regras baseadas em regex. Essas regras podem rodar em modo de bloqueio em produção e em modo de monitoramento ou com pontuação menor em staging.
Queries GraphQL excessivamente aninhadas podem gerar carga de processamento pesada com uma única requisição. A família de regras TR7 50101 detecta cadeias profundas `{ ... { ... } }` no nível de padrão e as inclui na decisão WAAP com pontuação alta.
Enviar múltiplas queries em um único corpo pode prejudicar a lógica clássica de rate limit. A regra TR7 50102 detecta padrões de query em lote e permite vincular esse comportamento a uma decisão de log, pontuação ou bloqueio.
Uma query GraphQL pode ser transportada não apenas no corpo bruto, mas também em campos JSON, de formulário ou de query string. As regras TR7 rodam nos escopos query, raw, json e form, colocando diferentes implementações de cliente sob a mesma política WAAP.
GraphQL Deep Inspection gerencia riscos específicos de GraphQL com regras WAAP baseadas em assinaturas, seleção de escopo e controles de hardening de endpoint.
A regra 50100 visa padrões comumente usados em introspecção GraphQL: `__schema`, `__type`, `IntrospectionQuery` e `fragment FullType`. O nível de risco padrão é posicionado como sinal de intensidade média e pode ser avaliado com pontuação 4. Em endpoints onde a introspecção deve ser fechada em produção, essa regra pode rodar em modo de bloqueio ou monitoramento. Tentativas de descoberta de schema tornam-se visíveis no fluxo de eventos WAAP.
A regra 50101 detecta queries GraphQL excessivamente aninhadas no nível de padrão. Cadeias profundas `{` e estruturas fortemente aninhadas podem fazer com que uma única requisição imponha alto custo de processamento ao backend. Essa regra pode ser avaliada com pontuação 6 como sinal de ataque mais forte. O objetivo não é realizar cálculo de complexidade com consciência de schema — é capturar padrões de query aninhada perigosos cedo.
A regra 50102 detecta padrões em lote onde múltiplas queries são enviadas em um único corpo. Como o query batching pode ser legítimo para alguns clientes, os valores de estado e pontuação da regra devem ser ajustados ao comportamento da aplicação. Começar em modo de monitoramento e clarificar com observação de tráfego real é a abordagem correta. Uma vez confirmado o abuso, a regra pode ser movida para política de bloqueio.
Junto com as regras enriquecidas TR7, o waf_db contém variantes GraphQL como as famílias 50100, 50101 e 21360+. Essas variantes cobrem grafias alternativas como `__schema {`, `__type`, `__typename` e padrões de mutation aninhada. Isso constrói uma superfície de assinatura mais ampla para comportamentos de introspecção e query aninhada sem depender de um único regex. Os operadores podem substituir o estado e a pontuação dessas regras por serviço.
Queries GraphQL nem sempre chegam no mesmo formato. Alguns clientes enviam os campos `query`, `variables` e `operationName` dentro de um corpo JSON; outros podem usar corpo bruto ou campos de formulário. As regras TR7 rodam nos escopos query, raw, json e form, colocando esses diferentes formatos de transporte sob cobertura de inspeção. Isso reduz o erro de confiar em apenas um formato de corpo em endpoints GraphQL.
Controles GraphQL podem ser aplicados tanto a alvos api_endpoint quanto web_application. O mesmo modelo de regra WAAP pode ser gerenciado com diferentes valores de estado, pontuação ou escopo dependendo do tipo de serviço. Por exemplo, a introspecção pode permanecer em modo de monitoramento em um endpoint de teste interno enquanto é bloqueada em um endpoint de produção público. Essa flexibilidade permite que um único conjunto de regras seja adaptado a diferentes políticas de ambiente.
Controles podem ser definidos para o endpoint `/graphql`, como permitir apenas o método POST, restringir chaves JSON esperadas para `query`, `variables` e `operationName`, ou aplicar um limite de tamanho de corpo. Esses controles não substituem as assinaturas GraphQL — eles são uma camada de segurança positiva que os complementa. Métodos inesperados ou campos JSON inesperados podem ser rejeitados em estágio inicial, tornando o comportamento do endpoint mais previsível.
Se o tráfego GraphQL inclui padrões de mutation específicos da aplicação, nomes de campo ou nomes de operação arriscados, eles podem ser adicionados como regras WAAP personalizadas. Por exemplo, uma palavra-chave `mutation` específica ou nome de operação sensível aparecendo no corpo pode receber uma pontuação mais alta. Essas regras personalizadas participam do sistema principal de pontuação WAAP e são visíveis no log e no fluxo SIEM. Mesmo sem inspeção de campo com consciência de schema, riscos específicos da aplicação podem ser capturados com regras baseadas em padrões.
GraphQL Deep Inspection é baseada em assinaturas em suas capacidades reais atuais — análise de operações, cálculo de complexidade e reivindicações de WAAP de campo com consciência de schema estão fora do escopo desta página.
Os controles GraphQL funcionam com uma abordagem de detecção de padrões baseada em regex e escopo. Diferenciação de tipo de operação, um contador de profundidade real ou cálculo de pontuação de complexidade de query não fazem parte desse modelo. Essa distinção é especialmente importante para posicionamento preciso.
As regras 50100, 50101, 50102 e variantes waf_db podem ser definidas como habilitadas, monitoramento ou desabilitadas dependendo da necessidade do serviço. Os valores de pontuação também podem ser ajustados à tolerância de falsos positivos da aplicação. O modelo correto de implantação para endpoints GraphQL em produção é começar em modo de monitoramento e migrar para bloqueio após observação de tráfego real.
Allow-list de método, allow-list de chave JSON e limite de tamanho de corpo podem ser aplicados em endpoints GraphQL. Esses controles garantem que o formato da requisição esteja em conformidade com o contrato esperado junto à detecção de assinaturas. Especialmente em APIs públicas, aceitar apenas o formato esperado no endpoint `/graphql` reduz a superfície de ataque.
O rate limiting por operação não é aplicado no nível do parser GraphQL. Não há reivindicação de análise semântica do número de operações dentro de um único corpo e aplicação de limite separado para cada uma. O padrão de query batching pode ser capturado como assinatura e usado junto com políticas gerais de rate limit.
Não há suporte dedicado para persisted queries dentro desta capacidade. Padrões GraphQL visíveis na requisição são inspecionados com assinaturas WAAP. Resolver uma query a partir do seu hash e verificá-la contra schema ou dados de operação registrada não é reivindicado nesta página.
A inspeção nativa no nível de um campo de schema GraphQL específico — por exemplo `User.email` — não é realizada. As regras funcionam com uma abordagem de correspondência de padrões contra o corpo. Se houver requisitos específicos de campo, eles devem ser tratados de forma limitada e cuidadosa com uma regra de regex personalizada.
Uma equipe de segurança pode permitir a introspecção em staging enquanto roda a regra 50100 em modo de bloqueio no endpoint de produção. Tentativas de descoberta de schema são registradas, pontuadas e bloqueadas por política.
Fragmentos ou estruturas de query excessivamente aninhados podem impor alto custo de processamento ao backend. A regra 50101 captura esses padrões com pontuação 6, fornecendo um sinal forte para a decisão de bloqueio WAAP.
Quando muitas queries são tentadas em uma única requisição a um endpoint de cliente mobile, a regra 50102 detecta o padrão em lote. A equipe de operações pode observar o comportamento em modo de monitoramento primeiro e mudar para modo habilitado assim que o abuso for confirmado.
Uma equipe de API pode permitir apenas o método POST e os campos JSON `query`, `variables` e `operationName` no endpoint `/graphql`. Métodos ou campos inesperados são rejeitados antes de chegar à aplicação, restringindo o comportamento do endpoint.
Torne visíveis e gerenciáveis os riscos de introspecção, DoS aninhado e query batching em produção. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.