O CAPTCHA está lá — mas não protege nada

Muitos responsáveis por sites adicionam um CAPTCHA ao formulário de contato, veem o pequeno selo ou a caixa de seleção aparecer e consideram resolvido o problema do spam. Mas o lixo continua chegando. Muitas vezes, o próprio CAPTCHA está correto — só não está conectado a nada que possa impedir um bot. Este artigo apresenta as formas típicas pelas quais reCAPTCHA, hCaptcha e Cloudflare Turnstile acabam como decoração e como verificar seus próprios formulários.

Onde a proteção realmente acontece

Os três serviços funcionam pelo mesmo princípio. Um script no navegador executa suas verificações e entrega ao formulário um token — uma sequência curta que diz “este visitante passou”. O token acompanha o envio do formulário até seu servidor. Só ali acontece a decisão real: seu servidor envia o token junto com uma chave secreta ao provedor e recebe uma resposta — sucesso ou falha e, no reCAPTCHA v3, também uma pontuação. Se qualquer elo dessa cadeia faltar, o widget continuará parecendo perfeitamente normal, mas um bot que enviar diretamente ao processador do formulário passará sem obstáculos.

A chave de teste que deixa tudo passar

Google, hCaptcha e Cloudflare publicam chaves especiais de teste para que desenvolvedores executem testes automatizados sem resolver desafios. Com o segredo de teste correspondente, a verificação sempre tem sucesso — essa é sua finalidade. Elas se destinam a ambientes locais e de homologação, mas frequentemente sobrevivem à passagem para produção: um desenvolvedor as cola durante a construção, o site entra no ar e ninguém as troca. Pelo menos o reCAPTCHA mostra no widget um aviso de que é apenas para testes, mas, em uma configuração invisível, quase ninguém olha. Se a chave de site de teste e o segredo de teste estiverem ambos em produção, todo envio passará, seja de uma pessoa ou de um bot; se apenas a chave de site for de teste, a verificação falhará e mensagens reais poderão ser rejeitadas.

Um token que ninguém verifica

O segundo clássico é um servidor que nunca consulta o provedor. O widget funciona, um token é criado e enviado e, então, o processador do formulário simplesmente o ignora. Origens típicas são formulários escritos à mão, trechos copiados que só cobrem o lado do navegador e configurações de plugin incompletas. Um caso parecido: o servidor chama o serviço de verificação, mas só confere se a requisição foi concluída, não o que a resposta diz. Ou o limite de pontuação do reCAPTCHA v3 é definido como 0, aceitando qualquer pontuação que o serviço possa retornar. Alguns processadores também aceitam em caso de falha: se o token faltar ou a verificação falhar, aceitam a mensagem mesmo assim — e um bot simplesmente omite o token.

Quando o widget nunca carrega de verdade

Outros erros de configuração quebram o lado do navegador. Se a chave de site não estiver registrada para o domínio — algo típico após a passagem da homologação para produção, mudança de domínio ou novo subdomínio —, o provedor se recusará a emitir tokens e mostrará um erro no widget ou no console do navegador. Após trocar o tema ou atualizar um plugin, a marcação do widget pode continuar na página enquanto o script que o faz funcionar desapareceu. Uma ferramenta de consentimento de cookies pode ter o mesmo efeito se bloquear o script do CAPTCHA até o visitante concordar. O que acontece depois depende do servidor: se exigir um token válido, visitantes reais não conseguirão mais enviar mensagens e ninguém perceberá as solicitações perdidas; se não exigir, os bots passarão livremente.

Mais dois casos são fáceis de ignorar. No reCAPTCHA v3, o selo no canto só mostra que o script está carregado em algum lugar da página — talvez pelo tema ou por outro plugin — enquanto a integração no próprio plugin de formulário está desativada. E plugins de cache podem armazenar uma página com um token incorporado ao HTML. Tokens de CAPTCHA só valem por alguns minutos e podem ser verificados uma única vez, então um token em cache falha para visitantes reais; a tentadora “correção” de desativar a verificação remove silenciosamente a proteção.

Uma autoverificação rápida

1. 1Abra a página do formulário em uma janela privativa, abra as ferramentas de desenvolvedor do navegador e procure erros do script de CAPTCHA no console.
2. 2Confira se o widget realmente aparece — antes e depois de aceitar o banner de cookies — e se o formulário não pode ser enviado enquanto ele estiver ausente.
3. 3No console administrativo do provedor, confira se a chave de site lista seu domínio em produção (incluindo variantes como www) e se as chaves do plugin ou código correspondem a ela — não chaves da documentação ou de uma configuração de homologação.
4. 4Nas configurações do plugin de formulário, confirme que a integração de CAPTCHA está ativada para esse formulário específico; no reCAPTCHA v3, confira se o limite de pontuação é maior que 0.
5. 5Se tiver acesso ao código, localize a verificação no servidor e confira se ela rejeita o envio quando a resposta é negativa ou o token está ausente.
6. 6Exclua a página do formulário do cache de página inteira ou garanta que o token seja criado novamente no navegador.
7. 7Envie uma mensagem real de teste e confira se ela chega; repita a verificação após mudanças no tema, nos plugins ou na ferramenta de consentimento.

Um CAPTCHA é uma camada, não toda a proteção. Combinado com um campo honeypot, uma verificação de tempo e filtragem no servidor, um erro de configuração em um ponto não deixa o formulário totalmente aberto. Se quiser uma visão rápida de como estão seus formulários, insira seu domínio em formexposed.com — o relatório mostra se as partes da configuração do CAPTCHA visíveis externamente estão em ordem.