| Tipo de honeypot | Como engana o bot | Quando usar |
|---|---|---|
| Campo oculto | Input escondido por CSS que o bot preenche e o humano ignora | Formulários de contato e comentários |
| Time-trap | Mede o tempo de preenchimento e rejeita envios em menos de 2 segundos | Bots que submetem em 200 ms |
| Token de sessão | Exige um valor gerado no carregamento da página, ausente no bot direto | Spam via requisição POST direta |
Legenda: o campo-armadilha aparece no HTML que o bot lê, mas fica invisível para o visitante humano.
## Os 3 tipos de honeypot e qual escolher Existem três tipos de honeypot em uso real, e a escolha depende do vetor de ataque. O campo oculto cobre cerca de 80% do spam de formulário; o time-trap pega bots que submetem em 200 ms; o token de sessão fecha o envio via POST direto sem carregar a página. A regra prática é combinar o campo oculto com o time-trap, porque cada um cobre uma fraqueza do outro: o primeiro pega o bot genérico, o segundo pega o que ignora campos ocultos mas envia rápido demais. Ferramentas como Contact Form 7, Akismet, Wordfence e All in One Security implementam variações dessas três abordagens, com graus diferentes de validação no servidor. O guia de combate a spam no WordPress detalha o impacto de cada camada no volume de envios indesejados e mostra quando o token de sessão vale o esforço de implementação. ## Como aplicar honeypot no formulário: Passo a passo Aplicar um honeypot no formulário leva cerca de 5 minutos e não exige escrever PHP do zero. A abordagem mais segura é usar um plugin que já trate o campo no servidor, porque esconder o input só no CSS deixa o bot que lê folha de estilo passar. Os passos abaixo cobrem o Contact Form 7, que tem extensão oficial de honeypot, e valem como modelo para o Elementor PRO. Antes de começar, faça backup, conforme o processo de hardening de segurança no WordPress. ### Instale a extensão honeypot do Contact Form 7 Adicione o plugin Contact Form 7 Honeypot pelo painel em Plugins e ative-o. Ele registra a tag `[honeypot]`, que você insere no editor do formulário com um name pouco suspeito, como `email_2`. O campo nasce escondido e validado no servidor, então o bot que o preenche é barrado sem mensagem visível ao humano. ### Configure o name e o rótulo acessível Defina um name plausível para o atacante (`website`, `email_confirm`) e mantenha o rótulo fora da tela com `aria-hidden="true"` e `autocomplete="off"`. Isso evita que um leitor de tela leia o campo e induza um usuário real a preenchê-lo, o que o marcaria como bot por engano. ### Ative o time-trap de 2 segundos Habilite a verificação de tempo mínimo de preenchimento, disponível no All in One Security e em extensões do Contact Form 7. Um envio que chega em menos de 2 segundos quase sempre é automação. O honeypot de campo combinado com esse time-trap derruba a maioria do spam residual. ## Por que o honeypot não para brute force de login O honeypot não para brute force de login porque protege o envio de formulários públicos, não o endpoint de autenticação `wp-login.php`. Um bot de força bruta não preenche campos visíveis: ele dispara requisições POST direto com pares de usuário e senha em sequência, ignorando qualquer armadilha do formulário de contato. Para esse vetor você precisa de limite de tentativas, bloqueio de IP e autenticação em dois fatores. O guia de proteção contra brute force no WordPress e o tutorial de configuração do Wordfence cobrem rate limiting e 2FA, que a armadilha de campo sozinha não entrega. Na prática, são duas frentes distintas: uma blinda o formulário público, a outra blinda a porta de login, e tratar as duas com a mesma ferramenta é o erro mais comum que a gente vê no suporte. ## Dados reais: Cves e o que o honeypot não cobre O honeypot reduz spam, mas não substitui a correção de vulnerabilidades no código dos plugins. Como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, a FULL é a única empresa brasileira autorizada a atribuir IDs CVE oficiais, então fala de falha de plugin com a autoridade de quem cataloga essas falhas. Um exemplo: o Contact Form 7 já teve a CVE-2020-35489, de CVSS 10.0, que permitia upload irrestrito de arquivos antes da 5.3.2, falha já corrigida. Nenhuma armadilha de campo teria parado essa exploração, que atacava o processamento de upload, não o spam de envio. Segundo o perfil público do WPVulnerability, o plugin hoje está seguro, com zero falhas sem patch, e seus CVEs corrigidos ao longo dos anos sinalizam manutenção ativa. Já o Elementor registra atenção, com a CVE-2023-48777 de CVSS 9.9 corrigida na 3.18.2. A categoria de falhas como o XSS mostra por que nenhum campo-armadilha substitui o patch. ## Quando o honeypot falha e o que combinar O honeypot falha contra bots avançados que leem CSS, executam JavaScript e ignoram campos com `display:none`, uma fatia crescente do tráfego malicioso. Nesses casos, o campo-armadilha some do alcance do bot e o spam passa. A defesa não pode terminar no formulário. Segundo o Cloudflare Radar, nos últimos 28 dias 82,4% dos ataques de camada de aplicação no Brasil foram mitigados como DDoS e 16,4% por WAF, o que mostra que parte relevante das ameaças nem chega ao formulário: é barrada na borda. Por isso a recomendação no suporte da FULL é empilhar a armadilha de campo com um firewall de aplicação, que age antes do PHP processar a requisição. O All in One Security reúne campo-armadilha, firewall e limite de login no mesmo plugin, o que reduz as lacunas entre camadas soltas. ## Decisão rápida: Honeypot, captcha ou firewall A escolha entre honeypot, captcha e firewall depende do que você protege e do atrito que aceita impor ao usuário. A armadilha de campo custa zero clique extra; o reCAPTCHA adiciona fricção visível; o firewall WAF opera na borda antes do PHP. A árvore abaixo resume a decisão para cada cenário comum num site WordPress, com base nos vetores mais frequentes no suporte.É um input escondido do usuário humano por CSS, mas presente no HTML do formulário. O bot automatizado preenche todos os campos, inclusive o oculto, e essa marca denuncia a automação. No servidor, o WordPress descarta qualquer envio em que o campo-armadilha venha preenchido. Por isso o método para spam sem pedir nenhum clique extra ao visitante real, ao contrário do reCAPTCHA.
Porque o brute force ataca o endpoint wp-login.php com requisições POST diretas, sem carregar o formulário visível onde o honeypot vive. O bot de força bruta nem vê o campo-armadilha: ele dispara pares de usuário e senha contra a autenticação. Para esse vetor é preciso limite de tentativas, bloqueio de IP e 2FA, recursos que o Wordfence e o All in One Security oferecem e que a armadilha de campo não cobre.
Sim, é possível e é justamente a maior vantagem dessa técnica. Ela bloqueia a maior parte do spam de formulário sem exibir nenhum desafio ao usuário, mantendo a taxa de conversão intacta. A extensão Honeypot do Contact Form 7 faz isso de forma gratuita e validada no servidor. Para spam residual de bots mais rápidos, some um time-trap de 2 segundos, que rejeita envios automáticos quase instantâneos.
A armadilha de campo detecta o bot pelo input oculto que ele preenche; o time-trap detecta pelo tempo de envio. Um humano leva mais de 2 segundos para preencher um formulário, enquanto o bot submete em cerca de 200 ms. O time-trap rejeita esses envios ultrarrápidos. As duas técnicas são complementares: o campo pega bots genéricos e o time-trap pega os que ignoram campos ocultos mas submetem rápido demais.
Um campo-armadilha bem configurado já basta para a maioria dos formulários, desde que validado no servidor e não apenas escondido por CSS. Adicionar dois ou três campos com names diferentes aumenta a captura contra bots que evitam um name específico, mas traz retorno decrescente. O ganho real vem de combinar a armadilha com um time-trap e, em sites muito visados, com um firewall de aplicação na borda.