← Voltar à lista

Rate limit, filas e antispam para formulários e bots

Rate limit, filas e antispam são três camadas de proteção - sem elas, formulários e bots do Telegram/Discord viram rápido canal de spam, flood e DoS. Um CAPTCHA não basta: é preciso limitar frequência, processar em assíncrono e filtrar por conteúdo e reputação. Abaixo - como montar um esquema prático para sites e bots sem complexidade extra.

  • Rate limit - quantas requisições são permitidas por janela de tempo a partir de um IP, conta ou token
  • Fila - buffer entre aceitar o pedido e o trabalho pesado (email, CRM, LLM, webhook)
  • Antispam - honeypot, CAPTCHA, heurísticas, blocklists e verificação de conteúdo
  • Regra - primeiro corte a frequência e processe em assíncrono; depois endureça os filtros
  • Objetivo - manter leads reais e não derrubar o serviço sob um botnet

Por que formulários e bots são atacados primeiro

Um endpoint público é uma porta sem tranca. Bots de spam caçam /contact, /api/lead e webhooks do bot e mandam milhares de mensagens: phishing, spam de SEO, credential stuffing, força bruta de cupons. Sem limites sobem as contas de email/SMS/LLM, o CRM enche de lixo e leads reais afogam no ruído.

Sintomas típicos:

  1. Pico de POSTs no formulário com zero conversões de venda
  2. Textos idênticos de IPs diferentes - ou lixo único de um mesmo intervalo
  3. Filas de email ou webhooks batem no limite do provedor
  4. O bot do messenger responde mais lento ou cai por timeout

Rate limit: o que limitar e como

O rate limiting responde: «quantas vezes em N segundos este endpoint pode ser tocado?». A chave do limite importa.

Chave Quando encaixa Risco
IP Formulários anônimos, webhooks sem auth NAT e redes corporativas cortam usuários bons
User / chat_id APIs autenticadas e bots Não protege antes do login
Token de API / sessão Integrações de parceiros Token roubado gasta toda a cota
Fingerprint + IP Antiabuso duro de formulários Mais difícil de implantar e explicar

Janelas práticas:

  • Formulário de leads: 3-5 envios bem-sucedidos por IP a cada 10 minutos, mais teto rígido para falhas (validação, CAPTCHA fail)
  • Login / OTP: separado e mais estrito - senão, força bruta
  • Comandos de bot: 1 resposta pesada (geração, busca) por usuário a cada poucos segundos; comandos leves - mais suave
  • Teto global no processo ou worker - protege picos mesmo com chaves diferentes

Ao exceder: HTTP 429 com Retry-After; no bot - um «aguarde N segundos» curto, sem revelar limiares internos. Registre os disparos: mostram se o limite está mole ou duro demais.

Filas: por que separar recebimento e processamento

O formulário não deve escrever no CRM, gerar PDF e chamar API externa de forma síncrona. Uma fila (Redis, RabbitMQ, SQS, Celery, BullMQ) pega a tarefa após a validação e responde rápido: «pedido aceito».

O que a fila oferece:

  • Suavização de picos - spam ou campanha não derruba processos web
  • Retry em falhas - retry com backoff em vez de perder o lead
  • Prioridades - pedidos pagos acima de «baixar PDF»
  • Isolamento - workers de LLM/email escalam separados do front

Fluxo do formulário:

  1. CSRF / origin, honeypot, validação básica dos campos
  2. Rate limit
  3. Gravar o lead no BD com status queued
  4. Push na fila
  5. HTTP 200/202 ao usuário
  6. Worker: scoring antispam → CRM / email / notificação

Igual nos bots: aceite rápido o update do Telegram; respostas pesadas (RAG, imagem, parsing) vão para a fila. Senão, long polling / webhook acumula latência.

Antispam: camadas, não uma checkbox

Um reCAPTCHA não fecha o assunto. Monte defesa em profundidade.

1. Filtros baratos na entrada

  • Campo honeypot (oculto para pessoas, preenchido por bots)
  • Tempo mínimo de preenchimento (rápido demais = bot)
  • Checagem de Referer / Origin e token CSRF
  • Limite de tamanho do body e do número de anexos

2. CAPTCHA e challenges

Mostre o challenge por sinal, não sempre: após N tentativas, IP suspeito ou score alto. CAPTCHA permanente fere conversão; pontual quase não.

3. Conteúdo e reputação

  • Blocklists de domínios/URL no texto
  • Detecção de templates repetidos e spam agnóstico a idioma
  • Checagem de email (MX, domínios descartáveis)
  • Em bots: filtro de links, stop words, limite de mídia

4. Sinais comportamentais

Histórico: quantos envios deste dispositivo viraram compra ou chat útil. IP novo com dezenas de «buy seo» por minuto - para quarentena ou revisão manual, não direto no CRM do vendedor.

Como ligar as três camadas

Ordem recomendada em produção:

  1. Validação e antispam barato (honeypot, tamanho, CSRF)
  2. Rate limit por IP + id de usuário/chat
  3. Resposta rápida ao cliente / messenger
  4. Fila com teto de jobs concorrentes por worker
  5. Antispam pesado e integrações no worker (scoring, CRM, email)
  6. Alertas em picos de 429 e crescimento de jobs rejeitados

Assim você não gasta CPU nem dinheiro de provedores em pedidos que o limite já deveria cortar.

Checklist de implantação

  • [ ] Formulário e bot têm limites diferentes conforme o risco
  • [ ] Há circuit breaker global para email/SMS/LLM de saída
  • [ ] 429 e mensagens do bot são claras, mas não ensinam a burlar
  • [ ] A fila tem DLQ (dead letter) e monitoramento de comprimento
  • [ ] Leads suspeitos vão para quarentena, não para exclusão silenciosa
  • [ ] Logs de rate limit e spam-score são úteis sem PII completa
  • [ ] Teste de carga: o que acontece a 100 RPS em /contact

Conclusão

O rate limit corta a frequência, a fila protege o backend e os orçamentos de integração, o antispam separa lixo de leads. Só funcionam juntos: limite sem fila derruba handlers síncronos; fila sem filtros espalha spam no CRM; filtros sem limite ficam caros sob DDoS.

Se precisar projetar proteção de formulários e bots para o seu stack (limites, fila, quarentena, monitoramento) - fale comigo. Orientações de suporte e melhorias - na página de preços.

Perguntas frequentes

Qual a diferença entre rate limit e antispam?

Rate limit conta tentativas; antispam avalia conteúdo e comportamento. O limite para flood mesmo com pedidos «limpos»; o antispam pega spam raro, mas tóxico, que ainda cabe na cota.

Preciso de fila se o volume de leads é baixo?

Sim, se houver APIs externas, email ou LLM. Mesmo com pouco tráfego, timeout síncrono do CRM quebra a UX do formulário. A fila é barata em ociosidade e salva no pico.

CAPTCHA é obrigatório em todo formulário?

Não. Prefira challenge por risco: após séries de erro, má reputação de IP ou score anômalo. Incomoda menos as pessoas e ainda corta bots.

No bot, limitar por chat_id ou por IP?

Ambos. chat_id freia flood de um usuário; IP/token do webhook protege de updates falsos e scanning. Em grupos os limites costumam ser mais duros que no privado.

O que fazer com leads que parecem spam?

Coloque em quarentena com revisão manual ou entrega adiada, não no lixo sem rastros. Senão perde um lead legítimo raro e não vê como os padrões de ataque evoluem.

Termos deste artigo

webhooks — HTTP callbacks when events happen — callbacks HTTP quando eventos ocorrem

LLM — Large Language Model — modelo de linguagem grande

CRM — Customer Relationship Management — gestão de relacionamento com clientes

PII — Personally Identifiable Information — informações pessoais identificáveis

DDoS — Distributed Denial of Service — negação de serviço distribuída

Contato