Limitar o abuso: rate limiting / throttling
Mesmo que uma requisição seja legítima, mil por segundo vindas do mesmo cliente
podem derrubar o seu serviço ou forçar senhas por força bruta. O rate
limiting conta as requisições por chave (IP, usuário, API key) dentro de uma
janela de tempo e, ao ultrapassar o máximo, as rejeita com o código de
status 429 Too Many Requests:
// pseudocódigo de um limitador por janela
if (contador(chave) >= MAX) {
return res.status(429).json({ error: "Muitas requisições" });
}
O throttling é a variante que desacelera em vez de cortar de uma vez.
Validar SEMPRE no servidor
A validação no cliente (no navegador) melhora a experiência, mas não
é segurança: o cliente está sob o controle do atacante, que pode pular o
formulário e chamar a sua API diretamente com curl.
Nunca confie no cliente. Toda entrada que chega ao servidor é validada outra vez no servidor: tipos, faixas, comprimentos, formato e regras de negócio. A validação do cliente é comodidade; a do servidor é a verdadeira barreira.
Defesas de alto nível: captcha e WAF
- Um captcha distingue humanos de bots e freia o cadastro em massa, o credential stuffing e o spam.
- Um WAF (Web Application Firewall) fica na frente da sua aplicação e inspeciona o tráfego para bloquear padrões de ataque conhecidos (injeção, scraping, DDoS) antes que cheguem ao seu código.
São camadas adicionais: complementam, não substituem, a validação e o escape dentro da sua aplicação.