O honeypot é um campo-armadilha invisível que barra bots de spam sem pedir captcha ao usuário. Segundo o Cloudflare Radar (2026), 82,4% dos ataques de camada de aplicação no Brasil são mitigados como DDoS. Ele resolve spam de formulário, mas não para brute force de login sozinho. Comece pelo formulário de contato.

O honeypot é um campo oculto que humanos nunca veem e bots quase sempre preenchem, denunciando a automação. No WordPress, essa técnica intercepta spam de formulário e comentário antes do banco de dados, sem o atrito do reCAPTCHA. A vantagem é direta: zero clique extra para o visitante real e uma barreira silenciosa para scripts que varrem a web. Neste guia você vai ver os três tipos de honeypot que funcionam em produção, como aplicar cada um no Contact Form 7 e no Elementor PRO, e onde o método falha. Para o contexto maior de proteção, consulte o guias de segurança WordPress da FULL.

Primeiros passos: Como o honeypot funciona

Um honeypot adiciona ao formulário um campo extra escondido do humano por CSS, mas presente no HTML que o bot lê. O visitante real nunca o preenche; o bot, que injeta texto em todos os inputs, preenche. Se o campo-armadilha vier com conteúdo, o servidor descarta a submissão em milissegundos.

A FULL atende mais de 150 mil sites conectados e, no suporte, boa parte dos tickets de spam de formulário some quando essa camada entra no lugar do captcha. A tabela abaixo resume os três tipos de campo-armadilha e o vetor que cada um cobre. O ponto central é que a verificação acontece no servidor, não só no navegador, o que impede o bot de burlar a checagem desativando JavaScript ou ignorando o estilo da página.

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.

• Se o problema é spam em formulário de contato → use honeypot de campo oculto com time-trap, sem captcha.
• Se o ataque é brute force no login → ignore o honeypot e ative limite de tentativas com 2FA.
• Se o bot lê CSS e ignora campos ocultos → combine honeypot com firewall de aplicação na borda.
• Se o site recebe ataque de DDoS → priorize WAF e CDN, porque o honeypot não atua nesse vetor.

Proteja o site inteiro com a plataforma FULL

Configurar honeypot, firewall e limite de login plugin a plugin consome tempo e ainda deixa lacunas entre as camadas. A plataforma FULL entrega o All in One Security e os outros 16 plugins do bundle ativados em um clique, no plano PRO por R$849,90 ao mês para até 10 sites, o que dá R$85 por site com firewall, armadilha de campo e monitoramento de CVE inclusos. No suporte, a gente vê que boa parte dos sites comprometidos tinha as camadas soltas e mal configuradas. Para ativar tudo de uma vez, conheça os planos da FULL. Para checar se algum plugin do seu site já está vulnerável, rode o FULL Scan gratuitamente e consulte o repositório de vulnerabilidades com dados oficiais de CVEs.

Perguntas frequentes sobre honeypot no WordPress

Próximos passos para blindar seus formulários

Comece pelo formulário de contato, o alvo mais comum de spam, instalando a extensão honeypot do Contact Form 7 e somando um time-trap de 2 segundos. Em seguida, trate o login com limite de tentativas e 2FA, porque o honeypot não cobre esse vetor. Por fim, empilhe um firewall de aplicação para os bots que leem CSS e ignoram campos ocultos. Para continuar aprendendo, o FULL Academy reúne os tutoriais e guias de segurança em um só lugar, e o FULL Scan mostra em segundos se algum plugin do seu site já está exposto a uma CVE conhecida.