reCAPTCHA validation failed: causas e soluções

A mensagem “reCAPTCHA validation failed” aparece quando o site não consegue confirmar que uma pessoa enviou o formulário e, por isso, rejeita o envio. Isso pode acontecer tanto ao marcar a caixa “Não sou um robô” quanto em uma verificação que ocorre em segundo plano, sem nada aparecer na tela. O Google retornou um resultado negativo, e o envio não foi concluído.

Se você só queria se cadastrar ou fazer login, a causa costuma estar do seu lado: um bloqueador de anúncios, por exemplo, ou uma página aberta há tempo demais. Se a verificação do reCAPTCHA falhou no seu próprio site, o mais provável é que o problema esteja nas configurações do reCAPTCHA ou no código do formulário.

Pontos principais

• No servidor, o código de erro indica a causa. Comece por ele. Se não houver um código, confira a secret key, depois a lista de domínios e, por fim, há quanto tempo o token foi gerado.
• Um token só é válido por dois minutos, e o Google só o verifica uma vez. Na v3, chame execute() quando o visitante clicar em Submit, e não ao carregar a página.
• Se o widget não aparecer, verifique se há um bloqueador de anúncios, uma regra de CSP ou um firewall impedindo o carregamento.
• A mensagem “captcha score is not above the threshold” está relacionada ao threshold definido pelo seu site ou plugin, não a um limite definido pelo Google.
• Os assessments do Enterprise dão mais detalhes sobre falhas de token. O siteverify agrupa tokens expirados e reutilizados no código timeout-or-duplicate, enquanto o Enterprise os identifica separadamente como EXPIRED e DUPE.

O que significa reCAPTCHA validation failed?

A verificação falhou em algum ponto: no navegador do visitante ou no seu servidor. O visitante vê o mesmo erro nos dois casos, mas a investigação começa em lugares diferentes.

Falha no lado do cliente: o widget não carregou ou o desafio não foi concluído

Quando o problema está no navegador, o token nem chega a ser criado. O widget pode não ter carregado — é isso que as pessoas geralmente querem dizer quando afirmam que o reCAPTCHA não está funcionando — ou o visitante pode não ter conseguido concluir o desafio com imagens. Nos dois casos, o backend não recebe um token: a requisição não chega ou chega com o campo g-recaptcha-response vazio. Com o Invisible reCAPTCHA, é mais difícil perceber a falha porque não há uma caixa de seleção na tela. Sem o tratamento adequado de erros, pode parecer que o formulário simplesmente parou de responder.

Falha no lado do servidor: success: false e códigos de erro

Quando o formulário exibe uma mensagem genérica como “Error verifying reCAPTCHA”, o token provavelmente saiu do navegador. O Google o rejeitou depois que o seu servidor o enviou para verificação, e a resposta do siteverify explica o motivo:

{
  "success": false,
  "error-codes": ["timeout-or-duplicate"]
}

Chaves baseadas em score também podem retornar success: true com um score abaixo do seu threshold. Nesse caso, quem rejeita a requisição é o seu código, e não o Google.

Conceitos: site key, secret key, token, score e threshold

Site key. É a chave pública do par. Ela fica visível no HTML ou no JavaScript da página.

Secret key. É a chave privada, que só o backend deve enviar ao siteverify. No Google Cloud, ela aparece como “legacy secret key”.

Token. É a string que o reCAPTCHA retorna após uma verificação: na v2, ela está em g-recaptcha-response. O Google aceita o token por dois minutos e só o verifica uma vez.

Score. É a pontuação de 0.0 a 1.0 retornada pela v3 e pelas chaves do Enterprise baseadas em score. Quanto maior o valor, menor o risco.

Threshold. É o limite mínimo de score aceito pelo site. Quem escolhe esse valor é você, não o Google.

Códigos de erro do reCAPTCHA: referência rápida

Os códigos vêm da resposta do siteverify ou de um assessment do Enterprise. Já as rejeições por score acontecem na verificação do threshold feita pelo seu código.

Por que a verificação do reCAPTCHA falha? Causas comuns

A solução depende de qual das quatro causas mais comuns está por trás do erro. O token pode ter expirado ou sido reutilizado, ou pode haver uma incompatibilidade entre as chaves e o domínio. Em outros casos, o widget não carrega ou o score fica abaixo do seu threshold.

Token expirado ou reutilizado: timeout-or-duplicate

O código timeout-or-duplicate indica que o token foi gerado há mais de dois minutos ou já foi verificado. Segundo a documentação do SiteVerify, cada token de resposta do reCAPTCHA tem validade de dois minutos e só pode ser verificado uma vez. Essa restrição evita ataques de repetição, também conhecidos como replay attacks.

• Em um formulário longo, o visitante marca a caixa primeiro e depois leva cinco minutos para preencher o restante. Na v2, adicione data-expired-callback para pedir que ele marque a caixa novamente.
• Uma página de checkout que solicita um token v3 ao carregar acaba enviando um token expirado se o comprador levar três minutos para preencher os dados do cartão. O Google recomenda executar a verificação no momento do envio do formulário, em vez de gerar o token com antecedência.
• Um clique duplo em Submit, ou um handler JavaScript executado junto com o evento nativo submit, envia o formulário ao servidor duas vezes. Desative o botão após o primeiro clique e só o reative se a requisição falhar.
• A verificação duplicada também pode acontecer no backend: um middleware verifica o token e, depois, o controller o envia novamente ao siteverify. Cada token deve ser verificado uma única vez por requisição.
• Depois de um erro no formulário, a próxima tentativa ainda pode carregar o token antigo. Na v2, chame grecaptcha.reset(); na v3, solicite um novo token.

O exemplo de v3 abaixo solicita o token no momento do envio e desativa o botão para impedir envios duplicados.

<form id="signup" action="/signup" method="POST">
  <!-- form fields -->
  <input type="hidden" name="g-recaptcha-response" id="g-recaptcha-response">
  <button type="submit" id="submit-btn">Sign up</button>
</form>

<script src="https://www.google.com/recaptcha/api.js?render=YOUR_SITE_KEY"></script>
<script>
  const form = document.getElementById('signup');
  const button = document.getElementById('submit-btn');

  form.addEventListener('submit', function (event) {
    event.preventDefault();
    button.disabled = true; // block double submit

    grecaptcha.ready(function () {
      grecaptcha.execute('YOUR_SITE_KEY', { action: 'signup' }).then(function (token) {
        document.getElementById('g-recaptcha-response').value = token; // fresh token at submit time
        form.submit();
      });
    });
  });
</script>

Secret key inválida e incompatibilidade de domínio: invalid-input-secret

Uma mensagem genérica como “Error verifying reCAPTCHA” costuma corresponder a invalid-input-secret nos logs do servidor: o Google considerou a secret key inválida ou malformada.

• A site key e a secret key foram trocadas entre a configuração do backend e o HTML.
• O código do frontend não corresponde ao tipo de chave: cada chave é criada como Score-based (v3) ou Challenge (v2).
• A chave foi recriada, mas o backend ainda usa a secret key antiga. A atual fica em Key Details → Integration → Use Legacy Key.
• A chave não está vinculada a um projeto do Google Cloud. O Google concluiu a migração automática das chaves Classic no primeiro trimestre de 2026 e bloqueou o acesso à API para chaves sem um projeto do Google Cloud. Se a integração parou de funcionar neste ano sem alterações no código, comece por essa verificação.
• Um deploy misturou chaves de teste e de produção. O Google oferece chaves de teste da v2 configuradas para sempre aprovar a verificação. Por isso, um par copiado de forma incompleta pode passar despercebido até a entrada em produção.
• Uma quebra de linha extra do arquivo .env acabou incluída na secret key.

O Enterprise retorna DOMAIN_MISMATCH quando a página que gerou o token está fora dos domínios permitidos para a chave. No ambiente local, a mensagem exibida é “Localhost is not in the list of supported domains.” Adicione o domínio exato às configurações da chave. Para localhost, o Google recomenda uma chave de desenvolvimento separada.

Com a opção Disable domain verification ativada, o Google deixa de verificar a origem dos tokens. Nesse caso, o seu código precisa comparar hostname com o domínio do site.

reCAPTCHA não carrega no navegador: browser-error

O código browser-error se refere a falhas que acontecem antes de o servidor participar da verificação. Em geral, um script ou iframe não terminou de carregar. A API Enterprise classifica BROWSER_ERROR como um erro que permite uma nova tentativa, como uma falha de rede. Por isso, o primeiro passo é chamar execute() novamente.

• Bloqueadores de anúncios ou de scripts podem impedir o carregamento. Na página de ajuda, o Google recomenda desativar plugins que possam entrar em conflito com o reCAPTCHA.

• Uma Content Security Policy restritiva pode bloquear o script. Nesse caso, o console do navegador mostra que um script ou frame foi bloqueado. O FAQ do Google lista as origens que devem ser incluídas nas diretivas:

  script-src  https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/
  frame-src  https://www.google.com/recaptcha/ https://recaptcha.google.com/recaptcha/
  connect-src https://www.google.com/recaptcha/

• Um firewall, proxy ou VPN que bloqueie os domínios do Google também impede o funcionamento do widget. Na rede do visitante, permita acesso a *.google.com, *.gstatic.com e *.recaptcha.net. Onde www.google.com não estiver acessível, o Google recomenda carregar o script de www.recaptcha.net e atualizar as demais referências a www.google.com/recaptcha/ de acordo com essa mudança.
• Qualquer chamada a grecaptcha feita antes do carregamento de api.js falhará. Coloque essas chamadas dentro de grecaptcha.ready() ou use o callback onload.
• Em páginas com vários widgets, grecaptcha.getResponse() e grecaptcha.reset() atuam no primeiro widget quando nenhum ID é informado. Renderize os widgets explicitamente e armazene cada ID retornado por grecaptcha.render().

Na v2 com checkbox, adicione data-error-callback. Conforme a orientação do Google, ao implementar esse callback, você também precisa avisar o usuário de que ele deve tentar novamente.

“Captcha score is not above the threshold” no reCAPTCHA v3

Essa mensagem aparece quando o Google aceita o token v3, mas retorna um score abaixo do threshold definido pelo site ou plugin. Como a integração está funcionando, a configuração a revisar é o threshold.

Na escala do Google, 0.0 indica alto risco e 1.0, baixo risco. O Google usa 0.5 como threshold nos exemplos de políticas de desafio, mas recomenda escolher os limites com base no tráfego real. Os scores do ambiente de staging podem ser diferentes dos de produção.

1. Registre os scores antes de bloquear requisições. Depois, escolha os thresholds com base nos dados de tráfego do console, como orienta o Google.
2. Defina um threshold separado para cada ação. O console apresenta dados das dez ações mais frequentes.
3. Para scores baixos, use uma verificação adicional em vez de recusar o acesso. A documentação do Enterprise sugere verificação por e-mail ou MFA para tentativas de login com score baixo.
4. Confira se o valor de action na resposta corresponde ao que você enviou.

Por exemplo, um formulário de newsletter pode aceitar scores a partir de 0.3, enquanto uma tentativa de login abaixo de 0.7 pode exigir um código enviado por e-mail, em vez de ser bloqueada.

Aplicativos móveis precisam de uma análise separada. As notas de versão do Google descrevem uma recalibração de scores no SDK móvel de 2026. Se os falsos positivos aumentarem após uma atualização do SDK, vale revisar os thresholds do aplicativo.

No Enterprise, projetos sem faturamento ativado recebem quatro níveis de score — 0.1, 0.3, 0.7 e 0.9 — em vez de 11.

Se um projeto sem uma conta de faturamento ativa exceder a cota gratuita de 10.000 assessments por mês, o siteverify retorna success: true com score fixo de 0.9 e a mensagem “Over free quota.”. Se todos os scores passarem a ser 0.9 de uma hora para outra, confira a cota primeiro.

O mesmo erro no Firebase, Adobe AEM e Zoho Forms

Essas plataformas exibem mensagens próprias quando o reCAPTCHA falha. A tabela relaciona cada mensagem à causa e à solução.

Exemplo de verificação do reCAPTCHA no servidor com PHP

Se a verificação do reCAPTCHA falhar no servidor, comece registrando o código de erro. Uma rejeição retornada pelo Google e uma falha na requisição ao Google precisam de tratamentos diferentes. No exemplo PHP abaixo, cada caso recebe uma resposta própria. O campo hostname é verificado para todas as chaves; na v3, também são verificados score e action.

<?php
$secretKey      = getenv('RECAPTCHA_SECRET');          // legacy secret key, server-side only
$expectedHost   = 'www.example.com';                   // your domain
$expectedAction = 'signup';                            // v3 only: action name set on the client
$threshold      = 0.5;                                 // v3 only: tune using your own traffic data

$token = $_POST['g-recaptcha-response'] ?? '';
if ($token === '') {
    http_response_code(400);
    exit('Please complete the CAPTCHA.');
}

$ch = curl_init('https://www.google.com/recaptcha/api/siteverify');
curl_setopt_array($ch, [
    CURLOPT_POST           => true,
    CURLOPT_POSTFIELDS     => http_build_query([
        'secret'   => $secretKey,
        'response' => $token,
        'remoteip' => $_SERVER['REMOTE_ADDR'] ?? '',
    ]),
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_TIMEOUT        => 10,
]);

$raw = curl_exec($ch);
if ($raw === false) {
    // Network problem between your server and Google, not a reCAPTCHA failure
    error_log('siteverify request failed: ' . curl_error($ch));
    curl_close($ch);
    http_response_code(503);
    exit('Verification service unavailable. Please try again.');
}
curl_close($ch);

$result = json_decode($raw, true);

if (empty($result['success'])) {
    $codes = $result['error-codes'] ?? ['unknown-error'];
    error_log('reCAPTCHA failed: ' . implode(', ', $codes));
    http_response_code(400);
    exit('Verification failed. Please try again.');
}

if (($result['hostname'] ?? '') !== $expectedHost) {
    http_response_code(400);
    exit('Verification failed: unexpected hostname.');
}

// v3 only: score and action checks
if (isset($result['score'])) {
    if (($result['action'] ?? '') !== $expectedAction || $result['score'] < $threshold) {
        http_response_code(403);
        exit('Additional verification required.');
    }
}

echo 'Verification successful';

A marcação do checkbox da v2 usa os atributos data-expired-callback e data-error-callback apresentados nas seções anteriores.

<!DOCTYPE html>
<html>
<head>
  <title>reCAPTCHA v2 checkbox</title>
  <script src="https://www.google.com/recaptcha/api.js" async defer></script>
</head>
<body>
  <form action="verify.php" method="POST">
    <div class="g-recaptcha"
         data-sitekey="YOUR_SITE_KEY"
         data-expired-callback="onCaptchaExpired"
         data-error-callback="onCaptchaError"></div>
    <br>
    <input type="submit" value="Submit">
  </form>

  <script>
    function onCaptchaExpired() { alert('The CAPTCHA expired. Please check the box again.'); }
    function onCaptchaError()   { alert('reCAPTCHA could not load. Check your connection and try again.'); }
  </script>
</body>
</html>

reCAPTCHA Enterprise vs. v2 checkbox: o que falha e por quê

O Google verifica tokens do Enterprise de forma diferente dos tokens da v2 com checkbox. Na v2, o siteverify informa se a verificação passou ou falhou e retorna um código de erro curto. Já um assessment do Enterprise explica com mais detalhes por que o token foi rejeitado. As diferenças de funcionamento e preço são abordadas em outro artigo: comparação de recursos e custos do reCAPTCHA v2, v3 e Enterprise.

Como a verificação funciona e o que vem na resposta

Na v2 com checkbox, o token aparece depois que o visitante clica em “Não sou um robô”. O backend envia o token e a secret key ao siteverify em uma requisição POST. A resposta contém success, challenge_ts, hostname e, quando há erros, um array error-codes. A resposta da v2 nunca inclui um score.

Os tokens do Enterprise são obtidos por grecaptcha.enterprise.execute() ou por um checkbox do Enterprise renderizado na página. Para verificar um token, o backend cria um assessment enviando uma requisição POST para: https://recaptchaenterprise.googleapis.com/v1/projects/PROJECT_ID/assessments.

O corpo da requisição contém o token, a site key e a ação esperada. O Google também recomenda enviar o user agent e o endereço IP do usuário.

{
  "event": {
    "token": "TOKEN",
    "siteKey": "KEY_ID",
    "expectedAction": "login",
    "userAgent": "USER_AGENT",
    "userIpAddress": "USER_IP"
  }
}

A resposta inclui tokenProperties (valid, invalidReason, hostname e action) e riskAnalysis (score e reasons).

Onde consultar o motivo da falha

Na v2, o erro do reCAPTCHA vem como um de seis códigos, sem detalhes adicionais. Se o visitante não concluir o desafio com imagens, nenhum token é criado e não há o que analisar no servidor.

O Enterprise é mais específico. Quando um token é rejeitado, invalidReason informa o problema, com valores como MALFORMED, EXPIRED, DUPE, MISSING, BROWSER_ERROR, UNEXPECTED_ACTION, KEY_MISMATCH e DOMAIN_MISMATCH. Para um token válido com score baixo, os motivos vêm em riskAnalysis.reasons: por exemplo, AUTOMATION, TOO_MUCH_TRAFFIC ou LOW_CONFIDENCE_SCORE. Este último indica que há pouco tráfego para uma análise confiável. Os códigos de motivo exigem uma conta de faturamento.

Diferenças na verificação de tokens

O endpoint siteverify usa a secret key para autenticação. Os assessments usam uma API key ou uma conta de serviço com o papel reCAPTCHA Enterprise Agent. Na v2, o backend só verifica success. No Enterprise, deve confirmar que tokenProperties.valid é true, que a ação corresponde à esperada e que o score atende ao threshold definido. O siteverify continua funcionando com chaves do Enterprise por meio da legacy secret key, mas o Google recomenda CreateAssessment para novas integrações.

Como são as configurações do console

No console independente reCAPTCHA Admin, a criação da chave fica em um único formulário. Você informa um Label, escolhe o tipo de chave — Score based (v3) ou Challenge (v2) — e adiciona os domínios. A chave é criada ao clicar em Submit.

No console do Google Cloud (Google Cloud Fraud Defense), o processo é dividido em duas etapas. A criação começa na aba Keys, pelo botão Create key. O formulário exibido contém os campos Display name, Application type e Domain list, além da opção Disable domain verification.

Desde abril de 2026, o reCAPTCHA faz parte do Google Cloud Fraud Defense. Segundo o Google, a mudança não afeta as funcionalidades existentes.

Com as policy-based challenge keys, disponíveis de forma geral desde outubro de 2025, o visitante recebe um desafio quando o score fica abaixo do threshold que você definiu. No Policy Engine, em Preview desde julho de 2026, é possível configurar regras por score, IP, user agent ou ASN.

Erros do Enterprise e da v2: sintoma, onde investigar e o que alterar

Como corrigir falhas na verificação do reCAPTCHA: checklist

Para usuários

Quando o reCAPTCHA falha em um site que você está acessando, a causa costuma ser um problema no navegador ou na rede que pode ser resolvido do seu lado.

• Recarregue a página antes de reenviar o formulário. Um token gerado há mais de dois minutos não é mais aceito.

• Atualize o navegador. O Google oferece suporte às duas versões principais mais recentes dos navegadores mais usados.

• Ative o JavaScript.

• Pause o bloqueador de anúncios para esse site.

• Desative a VPN ou tente usar outra rede.

• Se o problema persistir, entre em contato com o responsável pelo site.

Para responsáveis por sites

Se os problemas com o reCAPTCHA aparecerem no seu servidor, confira os pontos abaixo, um por um.

• Confirme que a site key e a secret key pertencem ao mesmo par e não contêm espaços ou quebras de linha extras.

• Confira se todos os domínios de produção estão cadastrados na chave.

• Verifique se a chave está vinculada a um projeto do Google Cloud.

• Solicite os tokens no momento do envio do formulário.

• Desative o botão Submit após o primeiro clique.

• Garanta que nenhum token seja verificado duas vezes.

• Após um erro no formulário, redefina o widget ou solicite um novo token.

• Verifique hostname no backend para todas as chaves e, na v3, confira também score e action.

• Permita na CSP as origens do reCAPTCHA indicadas pelo Google.

• Defina o threshold da v3 com base nos scores registrados nos logs.

• Registre nos logs os códigos de erro e hostname, sem incluir a secret key nem o token completo.

• Preserve os dados preenchidos pelo visitante após uma falha na verificação.

Leia também

• Como corrigir mensagens genéricas de “invalid captcha” em diferentes provedores de CAPTCHA
• Diferenças entre reCAPTCHA v2, v3 e Enterprise em recursos, scores e custos
• Por que o CAPTCHA não funciona: causas comuns e soluções

Testes automatizados de formulários com reCAPTCHA usando o CapMonster Cloud

Para testes automatizados dos seus próprios formulários, a API do CapMonster Cloud oferece suporte a reCAPTCHA v2, reCAPTCHA v3 e reCAPTCHA Enterprise, incluindo os tipos de tarefa RecaptchaV2Task, RecaptchaV3TaskProxyless, RecaptchaV2EnterpriseTask e RecaptchaV3EnterpriseTask. As instruções de configuração e os parâmetros de cada tarefa estão na documentação do CapMonster Cloud sobre reCAPTCHA.