Guias de Segurança
Limitação de taxa e controle de abuso: como projetar limites que barram força bruta e custos descontrolados
Limitação de taxa (rate limiting) não é desacelerar o tráfego; é decidir quem você conta, o que você conta e o que acontece no teto. O NIST limita as falhas consecutivas a 100, alertando que um bloqueio rígido nega o serviço a usuários reais, e o OWASP inclui limites de gasto na lista de limites de uma API.
A limitação de taxa (rate limiting) costuma falhar não porque o limite era frouxo demais, mas porque a pergunta errada foi feita. Antes de decidir "quantas por minuto", três perguntas precisam de resposta: quem você está contando, o que você está contando e o que acontece no teto.
Pergunta 1: quem você está contando?
Faça do IP o eixo principal e ele falha tanto contra atacantes quanto para usuários legítimos
Do lado do atacante: atrás de um proxy reverso ou CDN, o endereço de origem que a sua aplicação vê pode ser um valor escrito num cabeçalho. Confie incondicionalmente no X-Forwarded-For e reescrever um cabeçalho basta para ser contado como outra pessoa. Você acha que está contando e não está contando nada. Até onde esse cabeçalho merece confiança está em falsificação de X-Forwarded-For e proxies confiáveis.
Do lado do usuário legítimo: NAT corporativo e redes móveis fazem muitos usuários sem relação compartilharem um mesmo endereço. Limite por IP e você restringe pessoas que não estão atacando você.
Por isso o eixo principal deve ser um identificador ligado a quem age — uma conta, uma chave de API, uma sessão estabelecida —, com o IP somado como sinal de apoio. Nas etapas sem autenticação (antes do login) não há quem age para usar como chave, e é isso que as duas próximas perguntas precisam cobrir.
Pergunta 2: o que você está contando?
Um design que conta só requisições não consegue barrar uma única requisição cara. O OWASP API Security Top 10 detalha o que precisa de teto em API4:2023 "Unrestricted Resource Consumption" (consumo irrestrito de recursos).
O que você está contando
Requisições: 100/min → abaixo do limite ✓
↓ mas o que é de fato consumido é
CPU · tempo
uma varredura completa por chamada
Memória
uma entrada grande demais
Banda
dez mil registros
Dinheiro
chamadas cobradas repetidas
= esgotado sem nunca atingir o teto
- Tempo e memória
- Tempos limite de execução, alocação máxima de memória
- Recursos do SO
- Número de descritores de arquivo, número de processos
- Tamanho da entrada
- Tamanho máximo de arquivo enviado, tamanho máximo dos parâmetros de entrada
- Trabalho por requisição
- Número de operações executadas numa única requisição do cliente da API, registros retornados por página
- Dinheiro
- Limites de gasto com provedores terceiros e integrações de API (veja abaixo; o controle final contra dano financeiro)
Manter "100 requisições por minuto" não protege nada se uma requisição retorna dez mil registros, processa um arquivo enorme ou faz várias chamadas a uma API externa cobrada por uso. Ajuste a unidade que você conta ao que você está protegendo — CPU, memória, banda, dinheiro. Esse é o núcleo do design.
Pergunta 3: o que acontece no teto?
Esta é a parte mais mal compreendida. Mais rígido não é automaticamente mais seguro.
O efeito colateral do bloqueio rígido
"Três falhas e a conta é congelada" parece certo, mas também significa que um atacante pode congelar as contas de outras pessoas de propósito — você transformou o bloqueio em uma ferramenta de negação de serviço apontada para os seus próprios usuários. Você barrou a força bruta entregando um jeito de trancar as pessoas do lado de fora.
Projetar para "não vale a pena"
Desacelere as tentativas em vez de bloquear o acesso. O que o NIST SP 800-63B lista: exigir um CAPTCHA antes da autenticação, uma espera após uma tentativa falha que cresce à medida que a conta se aproxima do máximo permitido, uma lista de IPs a partir dos quais o titular já se autenticou antes e técnicas adaptativas ou baseadas em risco que avaliam se o comportamento está dentro do normal (endereço, geolocalização, horário, metadados do navegador).
O número do NIST é maior do que você espera: 100 falhas consecutivas
O NIST SP 800-63B declara que "o verificador DEVE (SHALL) limitar as tentativas de autenticação consecutivas que falharam numa única conta a no máximo 100". O conhecido "bloquear após três" não é o que a norma pede.
Por que 100 basta: com atrasos e um CAPTCHA no caminho, chegar a 100 deixa de ser viável em qualquer prazo útil. Dito ao contrário — apertar a contagem sem acrescentar atraso é o pior dos dois mundos: tranca usuários legítimos do lado de fora e ainda deixa um ataque automatizado gastar suas tentativas rapidamente.
Mais uma indicação prática do mesmo documento: numa autenticação bem-sucedida, os verificadores DEVERIAM (SHOULD) desconsiderar as tentativas falhas anteriores daquele usuário a partir do mesmo endereço IP. Decida também quando o contador zera — isso faz parte do design.
Onde aplicar o quê
Login (força bruta e credential stuffing)
Faça do contador de falhas por conta o eixo principal e aumente o atraso progressivamente. Use o IP como sinal de apoio, nunca como única base. Acrescentar a autenticação multifator faz com que uma senha correta não dê acesso imediato, o que torna a adivinhação não compensadora. Repare também que invasões recentes chegam cada vez mais com credenciais válidas em vez de adivinhá-las (a análise das vias de entrada de 2026) — a limitação de taxa é necessária, não suficiente.
Redefinição de senha e e-mail de confirmação (bombardeio de e-mails)
Conte tanto o que pode disparar um envio quanto quantos vão para o mesmo destino. Um formulário que aceita o endereço de outra pessoa deixa o atacante assediar um terceiro e prejudicar a sua reputação de envio ao mesmo tempo. Combine um tempo de espera por destino, um intervalo mínimo de reenvio e a exclusão de registros não confirmados (o que também reduz os dados pessoais não verificados que você guarda). O caminho de redefinição em si está em falhas de design na redefinição de senha.
Endpoints públicos e recursos de IA (picos de custo)
Conte o custo, não as requisições. Limite o tamanho da entrada, limite as operações executadas por requisição e configure sempre o limite de gasto do lado do provedor. Entre os cenários do OWASP há uma fatura que sobe de US$ 13 por mês para US$ 8.000. Ao ligar uma API externa cobrada por uso a um recurso público, garanta que exista uma camada que se mantém mesmo quando o seu código está errado. O que acontece quando uma chave vaza está em uma chave roubada, uma fatura e uma conta suspensa e uma chave de API vazada de código escrito por IA.
Operações caras (busca, exportação, processamento de arquivos)
Defina tetos explícitos para tempo de execução, memória, tamanho de upload e registros retornados por página. Qualquer lugar sem teto permite que uma única requisição esgote os seus recursos. Limite memória, CPU e número de processos também na camada de contêiner ou serverless, para que uma aplicação usando recursos inesperados seja parada de fora.
Saiba quando o teto está sendo atingido
Um limite que você não consegue observar é meio controle. Se ninguém vê que o teto está sendo alcançado, você não percebe nem um ataque em andamento nem usuários legítimos sendo trancados do lado de fora. Registre com que frequência os limites disparam e crie um alerta para picos. É o estado de "conseguir perceber que algo está errado" de a base de segurança para organizações, aplicado aqui.
A visão deste site: o objetivo de um limite é fazer o abuso não compensar
Trate a limitação de taxa como algo que bloqueia ataques por completo e você fica preso numa pergunta sem resposta: quantas tentativas são seguras? Vemos de outro jeito: trata-se do custo e do ganho do atacante. Aumente o custo do atacante por tentativa (tempo, computação, CAPTCHA, um segundo fator) e reduza o ganho esperado por tentativa (chance de acerto, até onde um acerto o leva). Você não precisa levar a taxa de sucesso a zero; precisa fazer com que não valha a pena.
É por isso que preferimos atrasos e um segundo fator a um bloqueio rígido. Dinheiro é o único caso em que esse raciocínio muda: o único teto confiável é o limite de gasto que fica fora do seu próprio código. O código às vezes está errado — coloque um controle fora do seu código para que um erro ainda assim não produza uma fatura sem limite.
Fontes (primárias)
- NIST SP 800-63B, "Digital Identity Guidelines: Authentication and Lifecycle Management" §5.2.2 Rate Limiting (Throttling) — pages.nist.gov (o SHALL que limita as falhas consecutivas a no máximo 100; CAPTCHA, esperas crescentes, listas de IPs permitidos e técnicas baseadas em risco; o SHOULD sobre desconsiderar falhas anteriores do mesmo IP após um sucesso)
- OWASP API Security Top 10 2023, "API4:2023 Unrestricted Resource Consumption" — owasp.org (os recursos que precisam de limites, o impacto no custo e a configuração de limites de gasto com terceiros)
Leia a seguir
- Comparando os grandes casos de 2026: o que KDDI, Aflac, a Agência Digital e a Sakura Internet têm em comum
- Caso real: uso indevido do registro CPR da Dinamarca (o acesso de consulta de um cliente legítimo foi usado indevidamente)
- Caso real: vazamento da Baitoru (até 3,88 milhões de endereços de e-mail) (coleta em massa por uma "falha de especificação" e limites de registros por usuário)
- Pré-requisito: falsificação de X-Forwarded-For e proxies confiáveis (a base para "quem você conta")
- Design: falhas de design na redefinição de senha / como escolher a autenticação multifator
- Custo: uma chave roubada, uma fatura e uma conta suspensa / uma chave de API vazada de código escrito por IA
FAQ
QQuantas falhas de login devem bloquear uma conta — três? cinco?
O NIST SP 800-63B exige que o verificador limite as tentativas de autenticação consecutivas que falharam numa única conta a no máximo 100. Três ou cinco não é exigência da norma. O que o mesmo documento pede, para não trancar usuários legítimos do lado de fora, é um CAPTCHA antes da autenticação, um tempo de espera que cresce à medida que a conta se aproxima do máximo permitido, uma lista de IPs a partir dos quais o titular já se autenticou antes e técnicas adaptativas ou baseadas em risco. Um bloqueio agressivo também dá ao atacante um jeito de congelar as contas de outras pessoas de propósito. Aumente o custo de cada tentativa em vez de só reduzir a contagem.
QLimitar por endereço IP basta?
Não. Atrás de um proxy reverso ou CDN, o endereço que a sua aplicação vê pode não ser a origem real: confie incondicionalmente no X-Forwarded-For e o atacante vira outro cliente só reescrevendo um cabeçalho, então você não está contando nada. E usuários legítimos compartilham endereços por NAT corporativo e redes móveis, então limites por IP também restringem usuários sem relação. Faça de um identificador ligado a quem age — conta, chave de API, sessão estabelecida — o eixo principal, e trate o IP como sinal de apoio.
QComo evito o bombardeio de e-mails de confirmação?
Você precisa tanto de um limite sobre quem pode disparar um envio quanto de uma contagem de quantos vão para o mesmo destino. Se o seu formulário aceita o endereço de outra pessoa, o atacante pode usar você para assediar um terceiro e, ao mesmo tempo, prejudicar a reputação de envio do seu domínio. Combine um tempo de espera por endereço de destino, um intervalo mínimo entre reenvios e a exclusão de registros nunca confirmados depois de um prazo — o que também reduz os dados pessoais não verificados que você guarda.
QQual é o maior perigo ao colocar uma API de IA por trás de um recurso público?
A fatura. O OWASP API Security Top 10 lista, em API4:2023 Unrestricted Resource Consumption, os limites de que uma API precisa — tempo limite de execução, memória, tamanho de upload, operações por requisição — e inclui junto os limites de gasto com provedores terceiros. Entre os cenários há uma fatura que passa de US$ 13 por mês para US$ 8.000. Limitar o número de requisições não protege você de operações que são caras individualmente. Configure o limite de gasto do lado do provedor: é o único teto que continua valendo quando o seu próprio código está errado.