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

Muitos proprietários de sítios Web acrescentam um CAPTCHA ao seu formulário de contacto, veem surgir o pequeno selo ou a caixa de verificação e consideram o problema do spam resolvido. Depois, o lixo continua a chegar. Muitas vezes, o próprio CAPTCHA está bem – só não está ligado a nada que possa travar um bot. Este artigo percorre as formas típicas como reCAPTCHA, hCaptcha e Cloudflare Turnstile acabam por ser mera decoração, e como verificar os seus próprios formulários.

Onde acontece realmente a proteção

Os três serviços funcionam segundo o mesmo princípio. Um script no navegador executa as suas verificações e entrega ao formulário um token – uma pequena cadeia de caracteres que diz «este visitante passou». O token segue com a submissão do formulário para o seu servidor. Só aí acontece a verdadeira decisão: o seu servidor envia o token, juntamente com uma chave secreta, ao fornecedor e recebe uma resposta – sucesso ou falha e, no caso do reCAPTCHA v3, também uma pontuação. Se faltar algum elo desta cadeia, o widget continua a parecer perfeitamente normal, mas um bot que envie diretamente para o processador do seu formulário passa sem obstáculos.

A chave de teste que deixa passar tudo

A Google, a hCaptcha e a Cloudflare publicam chaves de teste especiais para que os programadores possam executar testes automatizados sem resolver quebra-cabeças. Com o segredo de teste correspondente, a verificação tem sempre êxito – é esse todo o seu propósito. Destinam-se a ambientes locais e de staging, mas sobrevivem regularmente à passagem para produção: um programador cola-as durante o desenvolvimento, o sítio entra em funcionamento e ninguém as substitui. O reCAPTCHA, pelo menos, mostra no widget um aviso a dizer que se destina apenas a testes, mas com uma configuração invisível quase ninguém olha. Se a chave de site de teste e o segredo de teste estiverem ambos ativos, todas as submissões passam, quer venham de uma pessoa, quer de um bot; se apenas a chave de site for de teste, a verificação falha e as mensagens reais podem ser rejeitadas.

Um token que ninguém verifica

O segundo clássico é um servidor que nunca consulta o fornecedor. O widget funciona, é criado e submetido um token, e depois o processador do formulário simplesmente ignora-o. As origens típicas são formulários escritos à mão, excertos de código copiados que só cobrem o lado do navegador e definições de plugins deixadas a meio. Um parente próximo: o servidor chama efetivamente o serviço de verificação, mas só verifica se o pedido foi bem-sucedido, não o que diz a resposta. Ou o limiar de pontuação do reCAPTCHA v3 está definido como 0, o que aceita qualquer pontuação que o serviço possa devolver. Alguns processadores também «falham em aberto»: se o token faltar ou a verificação falhar, aceitam a mensagem na mesma – e um bot limita-se a omitir o token.

Quando o widget nunca chega realmente a carregar

Outras configurações erradas avariam, em vez disso, o lado do navegador. Se a chave de site não estiver registada para o domínio – típico após uma passagem de staging para produção, uma mudança de domínio ou um novo subdomínio –, o fornecedor recusa-se a emitir tokens e mostra um erro no widget ou na consola do navegador. Após uma mudança de tema ou uma atualização de plugin, a marcação do widget pode continuar na página, enquanto o script que lhe dá vida desapareceu. Uma ferramenta de consentimento de cookies pode ter o mesmo efeito se bloquear o script do CAPTCHA até o visitante aceitar. O que acontece a seguir depende do servidor: se exigir um token válido, os visitantes reais deixam de conseguir enviar mensagens e ninguém dá pelos pedidos perdidos; se não exigir, os bots passam livremente.

Há mais dois casos fáceis de passar despercebidos. Com o reCAPTCHA v3, o selo no canto só mostra que o script está carregado algures na página – talvez pelo tema ou por outro plugin –, enquanto a integração no próprio plugin de formulários está desativada. E os plugins de cache podem guardar uma página juntamente com um token incorporado no HTML. Os tokens CAPTCHA só são válidos durante alguns minutos e só podem ser verificados uma vez, pelo que um token em cache falha para os visitantes reais; a «solução» tentadora de desativar a verificação remove discretamente a proteção.

Uma breve autoverificação

1. 1Abra a página do formulário numa janela privada, abra as ferramentas de programador do navegador e procure na consola erros do script do CAPTCHA.
2. 2Verifique se o widget aparece efetivamente – uma vez antes e outra depois de aceitar o banner de cookies – e se o formulário não pode ser enviado enquanto o widget estiver em falta.
3. 3Na consola de administração do fornecedor, verifique se a chave de site inclui o seu domínio em produção (incluindo variantes como www) e se as chaves no seu plugin de formulários ou no seu código lhe correspondem – e não chaves da documentação ou de uma configuração de staging.
4. 4Nas definições do plugin de formulários, certifique-se de que a integração do CAPTCHA está ativada para este formulário específico; no caso do reCAPTCHA v3, verifique se o limiar de pontuação é superior a 0.
5. 5Se tiver acesso ao código, localize a verificação do lado do servidor e confirme que rejeita a submissão quando a resposta é negativa ou o token está em falta.
6. 6Exclua a página do formulário da cache de página completa, ou certifique-se de que o token é criado de novo no navegador.
7. 7Envie uma mensagem de teste real e verifique se chega; repita a verificação após alterações ao tema, aos plugins ou à ferramenta de consentimento.

Um CAPTCHA é uma camada, não a proteção completa. Combinado com um campo honeypot, uma verificação de tempo e filtragem do lado do servidor, uma configuração errada num ponto não deixa o formulário escancarado. Se quiser ter rapidamente uma ideia de onde estão os seus formulários, introduza o seu domínio em formexposed.com – o relatório mostra se as partes da sua configuração de CAPTCHA visíveis a partir do exterior estão em ordem.