Segurança em APIs GraphQL: Mitigação de Ataques DoS

A segurança em APIs GraphQL consolidou-se em 2026 como um requisito essencial para empresas que mantêm aplicações web e serviços móveis de alta escala. Embora a flexibilidade do GraphQL permita aos clientes solicitar dados estruturados em uma única chamada de rede, essa flexibilidade abre caminho para ataques de negação de serviço (DoS) baseados em consultas circulares hiper-aninhadas e problemas de amplificação de banco (N+1 Query Attacks).

Uma única consulta maliciosa de poucos kilobytes com dependências circulares (autor -> livros -> autor -> livros...) pode deflagrar milhões de requisições ao banco de dados, esgotando os pools de conexão e indisponibilizando o serviço.

Vetores de Sobrecarga em Infraestruturas GraphQL

Atacantes exploram a flexibilidade do protocolo principalmente por meio de:

1. Aninhamento Recursivo Profundo: Encadeamento excessivo de tipos relacionais para estourar a pilha de execução.
2. Duplicação de Campos via Alias: Inclusão massiva de subconsultas em uma única chamada HTTP para burlar limitadores de taxa tradicionais.
3. Paginação com Limites Excessivos: Envio de parâmetros como usuarios(first: 1000000) que esgotam a memória RAM do servidor.

Para otimizar o desempenho do código frontend e reduzir o tamanho de pacotes JavaScript, utilize nosso Minificador de CSS e JavaScript.

Matriz de Controles de Defesa em GraphQL

Vetor de Risco	Forma de Exploração	Impacto Operacional	Mecanismo de Controle
Aninhamento Profundo	Árvores relacionais cíclicas	Esgotamento de CPU e estouro de pilha	Limitação de profundidade AST (Depth Limiting)
Duplicação por Alias	Múltiplos alias em uma requisição	Contorno de rate limits	Análise de complexidade e custo de consulta
Requisições em Lote (Batching)	Arrays extensos em /graphql	Saturação de threads de execução	Desabilitar batching ou limitar a 5 itens
Vazamento por Introspecção	Consulta a __schema em produção	Mapeamento completo do schema	Desabilitar introspecção em ambientes públicos

Implementação de Limites de Profundidade em Node.js

Exemplo de configuração defensiva com validação AST no Apollo Server:

import { ApolloServer } from '@apollo/server';
import depthLimit from 'graphql-depth-limit';
import { createComplexityRule, simpleEstimator } from 'graphql-query-complexity';

const complexityRule = createComplexityRule({
  maximumComplexity: 1000,
  estimators: [
    simpleEstimator({ defaultComplexity: 1 })
  ],
  onCost: (cost) => {
    console.log(`Custo computacional da consulta: ${cost}`);
  }
});

export const server = new ApolloServer({
  typeDefs,
  resolvers,
  introspection: process.env.NODE_ENV !== 'production',
  validationRules: [
    depthLimit(6),
    complexityRule
  ]
});

A validação prévia na AST descarta consultas abusivas em microssegundos sem onerar o banco de dados.

Recomendações de Segurança para Ambientes de Produção

Para assegurar estabilidade contínua:

1. Uso de Dataloaders: Agrupe consultas ao banco de dados para eliminar sobrecargas N+1.
2. Persisted Queries: Permita em produção somente consultas pré-registradas identificadas por hashes criptográficos.
3. Validação de Payloads JSON: Inspecione parâmetros de entrada com nosso Validador de JSON.
4. Verificação de Tokens: Valide cabeçalhos de autenticação de acordo com nosso estudo em JWT ES256 vs RS256.
5. Sanitização de Parâmetros: Proteja resolvers contra injeções conforme orientado em Sanitização de Consultas SQL.

Resumo

A versatilidade do GraphQL deve ser respaldada por controles de segurança rigorosos. A imposição de limites de profundidade e o cálculo de complexidade computacional protegem as APIs contra indisponibilidades.

Limitação de Taxa Baseada em Custo de Consulta no GraphQL

Limitadores de taxa tradicionais baseados na contagem de requisições HTTP por minuto são ineficazes no GraphQL, uma vez que uma única requisição com custo computacional de 5.000 pontos pode causar maior degradação do que milhares de consultas simples de 1 ponto.

O modelo de Limitação Baseada em Custo debita a complexidade calculada do saldo de tokens do cliente. Ao esgotar sua cota, o gateway responde com o código de status 429 Too Many Requests e cabeçalho Retry-After.

Middleware de Controle por Custo em TypeScript

interface ClientQuota {
  tokensRemaining: number;
  lastRefill: number;
}

const clientBuckets = new Map<string, ClientQuota>();
const REFILL_RATE_PER_SEC = 50;
const MAX_CAPACITY = 1000;

export function costRateLimiter(clientIp: string, calculatedCost: number): boolean {
  const now = Date.now();
  let bucket = clientBuckets.get(clientIp) || { tokensRemaining: MAX_CAPACITY, lastRefill: now };

  const elapsedSecs = (now - bucket.lastRefill) / 1000;
  bucket.tokensRemaining = Math.min(MAX_CAPACITY, bucket.tokensRemaining + elapsedSecs * REFILL_RATE_PER_SEC);
  bucket.lastRefill = now;
  clientBuckets.set(clientIp, bucket);

  if (bucket.tokensRemaining >= calculatedCost) {
    bucket.tokensRemaining -= calculatedCost;
    return true;
  }
  return false;
}

Bloqueio de Inundação por Lotes e Timeouts Rígidos

Para proteger os microsserviços, os gateways de borda devem limitar o processamento em lote e impor timeouts estritos em todos os resolvers do schema.

---

Normas e Guias:

• OWASP API Security Top 10: API4:2023 Unrestricted Resource Consumption.
• GraphQL Foundation: Security Best Practices.
• Guia TecnoCrypter: Validação Segura de Tokens JWT.