O que realmente protege um formulário: CAPTCHA, honeypot, armadilha de tempo, CSRF

Spam por formulários de contato raramente vem de uma pessoa digitando à mão. Na maioria das vezes, é software que encontra formulários, preenche todos os campos e envia o resultado — milhares de vezes. Existem várias defesas, e elas atuam em pontos muito diferentes. Saber o que cada uma realmente faz ajuda a evitar dois erros: um formulário sem proteção real e um formulário tão protegido que as pessoas desistem.

Honeypot e armadilha de tempo: filtros invisíveis

Um honeypot é um campo extra que as pessoas nunca veem, como um campo chamado “website” oculto com CSS. Bots simples preenchem todos os campos, então um honeypot preenchido sinaliza automação e o servidor pode descartar a mensagem silenciosamente. Bots feitos para seu site ou que renderizam a página como um navegador o ignoram. Oculte-o corretamente: um campo apenas deslocado para fora da tela pode ser anunciado por leitores de tela, alcançado pela tecla Tab ou preenchido automaticamente. Use aria-hidden, tabindex -1 e autocomplete off, além de um rótulo neutro pedindo a quem chegar ali que o deixe vazio.

Uma armadilha de tempo registra quando o formulário foi entregue e rejeita envios que chegam rápido demais para serem plausíveis. Pessoas precisam de alguns segundos para ler e digitar; muitos scripts enviam em uma fração de segundo. O registro de tempo deve ser conferido no servidor e protegido contra adulteração, por exemplo, com assinatura ou mantido na sessão — um simples campo oculto de tempo é reescrito pelo bot. Mantenha o limite baixo, pois o preenchimento automático também torna pessoas reais rápidas. Bots que simplesmente esperam passam: uma armadilha de tempo é um filtro, não um muro.

CAPTCHA: eficaz, mas tem um custo

Um CAPTCHA pede uma prova de que não há um bot agindo — desde desafios de imagens até verificações em segundo plano; serviços comuns incluem reCAPTCHA, hCaptcha, Cloudflare Turnstile e Friendly Captcha. Ele impede a maioria das automações genéricas, por isso é tão popular. Mas cada desafio visível é um obstáculo em que alguns visitantes desistem, e a maioria dos serviços carrega um script de terceiros, o que levanta questões de privacidade e consentimento. Um CAPTCHA também só ajuda se estiver configurado corretamente: uma chave pública de teste, um widget sem seu script ou um token que o servidor nunca verifica parecem proteção, mas não são. Uma verificação gratuita em formexposed.com aponta esses erros externamente.

A acessibilidade faz parte desse custo. Desafios de imagens excluem pessoas cegas e muitas com baixa visão, alternativas de áudio não ajudam pessoas surdocegas e tarefas difíceis de lógica sobrecarregam pessoas com deficiências cognitivas. O critério de sucesso 1.1.1 das WCAG 2.2 exige uma alternativa textual que descreva a finalidade do CAPTCHA e formas alternativas para diferentes sentidos. Verificações em segundo plano evitam a maior parte disso, mas, quando detectam algo suspeito, a alternativa costuma ser novamente um desafio visual — teste esse caminho com teclado e leitor de tela.

Token CSRF: proteção contra falsificação, não contra spam

Um token CSRF é um valor aleatório que o servidor coloca no formulário e espera receber de volta. Foi concebido contra falsificação de requisições entre sites, em que outro site faz o navegador de um visitante enviar uma requisição que ele nunca pretendeu fazer. Em um formulário de contato público, há um efeito secundário: bots que enviam diretamente ao endereço do formulário sem carregar a página são rejeitados. Qualquer bot que consulte a página e devolva o token passa. A maioria dos frameworks e plugins de formulário já inclui tokens CSRF — mantenha-os ativados, mas não os considere proteção contra spam.

O que precisa acontecer no servidor

• Valide novamente cada campo no servidor: campos obrigatórios, tamanho, formato de e-mail e ausência de quebras de linha em campos que acabam nos cabeçalhos de e-mail.
• Verifique os tokens de CAPTCHA e prova de trabalho em cada envio, com o serviço emissor ou em seu próprio código, e rejeite tokens reutilizados.
• Limite os envios por endereço IP e intervalo de tempo. Isso impede enxurradas de uma origem; spam distribuído por muitos endereços exige outras camadas.
• Considere a prova de trabalho: antes de enviar, o navegador resolve uma pequena tarefa computacional. Visitantes não veem desafios e nada é rastreado, mas o envio em massa fica caro.

Uma combinação sensata: duas ou três camadas

1. 1Comece pelas camadas invisíveis: um honeypot acessível e uma armadilha de tempo assinada, ambos verificados no servidor.
2. 2Adicione um limite de frequência por endereço IP para que uma única origem não possa inundar o formulário.
3. 3Se spam direcionado ainda passar, adicione prova de trabalho ou um CAPTCHA — de preferência sem desafio visível e com alternativa acessível.
4. 4Mantenha o token CSRF fornecido pelo seu framework — como bônus, não como defesa.
5. 5Teste o resultado como visitante — só com teclado, com leitor de tela, no celular — e confira se mensagens reais continuam chegando.

Em muitos sites, honeypot, armadilha de tempo e limite de frequência juntos já eliminam a maior parte do spam genérico sem obstáculo visível; o CAPTCHA fica como reserva quando isso não basta. No WordPress, o plugin gratuito formexposed combina honeypot, verificação de tempo e prova de trabalho sem precisar do Google. Para ver o que seu formulário mostra externamente — quais camadas estão presentes, se um CAPTCHA está configurado de forma eficaz —, uma verificação gratuita em formexposed.com só precisa de um domínio, sem conta. Ela não pode ver o código do seu servidor, então a parte do servidor continua sendo sua tarefa.