Rate limiting em Node.js: como proteger suas APIs contra sobrecarga e abusos sem afetar a UX

Toda API pública vai, cedo ou tarde, receber mais requisições do que deveria. Às vezes é um ataque. Muitas vezes é um app com bug fazendo a mesma chamada em loop, ou um parceiro integrando sem cache. Sem rate limiting, a consequência é a mesma: servidor sobrecarregado, banco no limite e todos os clientes sofrendo por causa de um só.

O que é rate limiting

É definir quantas requisições um mesmo cliente pode fazer num intervalo de tempo — por exemplo, 100 por minuto por IP, ou 5 tentativas de login a cada 15 minutos. Passou do limite, a API responde 429 Too Many Requests em vez de processar.

O básico no Express

import rateLimit from 'express-rate-limit'

export const apiLimiter = rateLimit({
  windowMs: 60_000,      // 1 minuto
  limit: 100,            // requisições por janela
  standardHeaders: 'draft-7',
  legacyHeaders: false,
})

app.use('/api/', apiLimiter)

Isso já protege bastante. Mas um único limite global raramente é o certo.

Limites diferentes para riscos diferentes

• Login e recuperação de senha: limites baixos, por IP e por conta. É a principal defesa contra força bruta (Ataques de força bruta no login: bloqueio progressivo sem punir o usuário honesto).
• Rotas de leitura: limites generosos; derrubar quem só está navegando prejudica a UX.
• Rotas caras (relatórios, exportações, chamadas a IA): limites por usuário autenticado, não por IP.
• Webhooks de parceiros: listas de permissão em vez de limite cego.

Os erros que mais vemos

• Limitar por IP atrás de proxy ou CDN sem configurar trust proxy — todo mundo vira o mesmo IP e o limite bloqueia a empresa inteira.
• Guardar contadores em memória com vários servidores: cada instância conta sozinha e o limite real vira 3x, 5x o planejado. A solução distribuída está em Rate limit distribuído com Redis: quando um servidor não basta.
• Responder 429 sem o cabeçalho Retry-After, deixando o cliente sem saber quando tentar de novo.

O outro lado: a experiência de quem recebe o 429

Bloquear é metade do trabalho. A outra metade é o app reagir com elegância: mensagem clara, botão desabilitado com contagem regressiva e retentativa inteligente. Mostramos isso em Gerenciando o erro 429 Too Many Requests: exponential backoff e retry no cliente e, para apps, em Erro 429 no app: como avisar o usuário e tentar de novo sem travar.

Na We Codex, rate limit faz parte do pacote de Segurança Anti-Hacker de todo sistema que entregamos. Se a sua API ainda está exposta, fale com a gente.