Como funciona a pontuação do reCAPTCHA v3: mecanismo de risco, sinais e proxies residenciais

O reCAPTCHA v3 mudou o paradigma da verificação anti-bot: em vez de desafios visíveis, ele atribui um score contínuo de 0.0 a 1.0 a cada ação do usuário. Entender como funciona a pontuação do reCAPTCHA v3 é essencial para engenheiros de QA, equipes de automação e pesquisadores de anti-bot que precisam operar dentro dos limites legais e técnicos das plataformas. Neste guia, vamos dissecar o motor de risco, os sinais que o Google funde, por que IPs de datacenter colapsam o score e como proxies residenciais como o ProxyHat ajudam a manter a pontuação acima do limite.

Como funciona a pontuação do reCAPTCHA v3: o modelo de score contínuo

O reCAPTCHA v3, introduzido pelo Google em 2018, abandona o clássico "clique nos semáforos". Em vez disso, ele retorna um score de risco por ação via grecaptcha.execute(). Cada chamada inclui um parâmetro action (por exemplo, login, signup, checkout) que identifica o contexto da interação. O score é devolvido no cliente como um número de ponto flutuante entre 0.0 e 1.0, e novamente no servidor após a verificação via siteverify.

O Google agrupa o tráfego em onze buckets de score discretos: 0.0, 0.1, 0.2, …, 0.9, 1.0. Embora o valor retornado seja contínuo, o backend do Google o arredonda internamente para esses buckets ao alimentar modelos de telemetria. Sites podem configurar limiares próprios, mas os padrões típicos observados na prática são:

• Score < 0.3: bloqueio automático ou desafio secundário (frequentemente reCAPTCHA v2 fallback ou verificação por email).
• Score entre 0.3 e 0.6: desafio ou fricção adicional (MFA, CAPTCHA interativo, verificação por SMS).
• Score > 0.6: tráfego permitido sem fricção.

O guia oficial do reCAPTCHA v3 do Google recomenda que cada site calibre seus próprios limiares com base no tráfego histórico. O score é relativo, não absoluto: um 0.7 em um site de e-commerce pode significar algo diferente de um 0.7 em um fórum pequeno.

O fluxo de execução no cliente

Quando a página carrega, o script https://www.google.com/recaptcha/api.js?render=SITE_KEY é injetado. Em seguida, o desenvolvedor chama:

grecaptcha.execute(SITE_KEY, { action: 'login' }).then(token => {
  // envia o token para o servidor
  fetch('/verify', { method: 'POST', body: JSON.stringify({ token, action: 'login' }) });
});

O token retornado é uma string opaca de aproximadamente 500-800 caracteres com validade de cerca de 2 minutos. O servidor deve consumir esse token imediatamente via siteverify.

Os sinais que o Google funde no motor de risco

O reCAPTCHA v3 não revela oficialmente a lista completa de sinais, mas engenharia reversa, documentação parcial e observações empíricas permitem mapear as principais categorias. O motor combina sinais comportamentais, reputação de IP, características do navegador e o grafo de cookies do Google em um modelo de aprendizado de máquina que produz o score final.

1. Telemetria de interação com a página

O script do reCAPTCHA captura eventos de mouse, scroll e teclado: velocidade do movimento do cursor, pausas entre cliques, padrões de scroll (suave vs. instantâneo), tempo entre keydown e keyup, e a sequência de foco em campos de formulário. Bots que preenchem formulários instantaneamente ou que não geram eventos de mouse recebem scores baixos porque o perfil comportamental diverge de humanos reais.

Pesquisas como o estudo de Sivakorn et al. sobre o reCAPTCHA demonstram que o Google usa modelos de aprendizado treinados em bilhões de interações para distinguir padrões humanos de automatizados. A entropia dos movimentos é um fator significativo.

2. Grafo de cookies do Google

Se o usuário estiver logado em uma conta Google (Gmail, YouTube, Android), o cookie NID e SID vinculam a sessão a um histórico de identidade. Um usuário com conta ativa há anos, com atividade consistente, tende a receber scores altos. Sessões limpas, sem cookies do Google e sem histórico, são tratadas com desconfiança — especialmente quando combinadas com IPs suspeitos.

3. Características do navegador e fingerprints TLS

O reCAPTCHA inspeciona o User-Agent, a lista de plugins, o navigator.languages, a disponibilidade de APIs como WebGL e Canvas, e a consistência entre o UA declarado e os recursos suportados. Mais importante para automação: o Google também coleta a fingerprint TLS do cliente. O JA3/JA4 fingerprint — que codifica a ordem das cifras e extensões TLS — é comparado contra o esperado para o navegador declarado. Um requests em Python, por exemplo, apresenta um JA3 que não corresponde a nenhum Chrome real, e isso é um sinal imediato de automação.

Outros sinais de JavaScript incluem: navigator.webdriver (verdadeiro em Selenium sem stealth), window.chrome ausente em headless puro, e a assinatura do Canvas API que difere entre motores de renderização reais e emulados.

4. Reputação de IP

Este é o ponto crítico para quem usa proxies. O Google mantém um banco de reputação de IPs que classifica endereços por ASN, tipo (datacenter, residencial, móvel), volume de tráfego suspeito observado e histórico de abuso. IPs de datacenter conhecidos (AWS, DigitalOcean, OVH, Hetzner) recebem penalidades severas no score, frequentemente resultando em scores entre 0.1 e 0.3 independentemente do comportamento. O mesmo navegador, os mesmos cookies, os mesmos movimentos de mouse — mas atrás de um IP 54.x.x.x da AWS — colapsam o score.

É por isso que proxies residenciais são necessários: eles apresentam IPs que pertencem a ASNs de ISPs reais (Comcast, AT&T, Vivo, Deutsche Telekom), com reputação de tráfego humano orgânico. O IP-reputation component do reCAPTCHA é um multiplicador que pode elevar ou destruir o score final.

Por que datacenter e IPs marcados colapsam o score

Considere um cenário de teste: você configura um navegador Playwright real, com stealth plugin, movimentos de mouse humanizados, cookies do Google válidos de uma sessão autenticada, e executa uma ação login. Atrás de um IP residencial, o score pode ser 0.8. Atrás de um IP de datacenter, o mesmo setup retorna 0.2. A diferença não está no comportamento — está na reputação do IP.

O Google não publica os pesos exatos, mas testes empíricos da comunidade de segurança mostram que a reputação de IP pode contribuir com 30-50% do score final quando outros sinais são ambíguos. Para um IP recém-flaggado por tráfego de scraping agressivo, o score pode cair para 0.1 mesmo com comportamento perfeito.

É aqui que o ProxyHat entra: com uma pool de proxies residenciais rotativos, você apresenta IPs que pertencem a ISPs reais e que não estão marcados por abuso recente. Isso eleva o componente de reputação de IP e permite que os sinais comportamentais positivos (browser real, cookies, interação humana) efetivamente contribuam para um score acima de 0.6.

Verificação server-side: siteverify, action e hostname

O token gerado no cliente não é o score final. O servidor deve enviar uma requisição POST para https://www.google.com/recaptcha/api/siteverify com três parâmetros:

• secret: a chave secreta do site.
• response: o token recebido do cliente.
• remoteip (opcional): o IP do cliente.

O JSON retornado inclui:

{
  "success": true,
  "score": 0.7,
  "action": "login",
  "challenge_ts": "2026-01-15T12:00:00Z",
  "hostname": "example.com",
  "error-codes": []
}

Dois campos exigem validação explícita no backend:

1. Action deve corresponder: se o cliente executou grecaptcha.execute(KEY, { action: 'login' }), o servidor deve verificar que response.action === 'login'. Se houver mismatch, o token deve ser rejeitado. Um atacante pode capturar um token de uma ação de baixo risco (ex: page_view) e tentar reusá-lo em uma ação de alto risco (ex: checkout).
2. Hostname deve corresponder: o campo hostname na resposta deve bater com o domínio esperado. Tokens gerados em evil.example não devem ser aceitos em example.com.

Um erro comum é confiar apenas em success: true. Sem validar action e hostname, o sistema fica vulnerável a replay attacks cross-site.

Abordagem legítima com ProxyHat: browser real + proxies residenciais

Para automação legítima — QA de acessibilidade, testes de carga autorizados, pesquisa de segurança com consentimento — a estratégia é combinar um navegador real (não headless puro) com proxies residenciais do ProxyHat e interação humanizada. O objetivo não é "burlar" o reCAPTCHA, mas sim apresentar um perfil de tráfego genuíno que o motor de risco classifica como legítimo.

Configuração do proxy no ProxyHat

O ProxyHat usa um gateway único com parâmetros de geo-targeting e sessão no username. Para tráfego residencial nos EUA:

http://user-country-US:SUA_SENHA@gate.proxyhat.com:8080

Para uma sessão fixa (sticky) que mantém o mesmo IP por um período:

http://user-country-US-sid-abc123:SUA_SENHA@gate.proxyhat.com:8080

Para SOCKS5:

socks5://user-country-US:SUA_SENHA@gate.proxyhat.com:1080

Consulte a documentação oficial do ProxyHat para detalhes completos de configuração.

Exemplo em Python com Playwright

O exemplo abaixo usa Playwright com um perfil de navegador não-headless, proxy residencial do ProxyHat e interação humanizada. É um padrão apropriado para testes de QA em ambientes de staging que implementam reCAPTCHA v3:

from playwright.sync_api import sync_playwright
import time, random

PROXY = "gate.proxyhat.com:8080"
PROXY_USER = "user-country-US"
PROXY_PASS = "SUA_SENHA"

PROXY_URL = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY}"

def human_delay(min_s=0.5, max_s=2.0):
    time.sleep(random.uniform(min_s, max_s))

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # navegador visível = melhor fingerprint
        proxy={"server": PROXY_URL}
    )
    context = browser.new_context(
        viewport={"width": 1366, "height": 768},
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
        locale="en-US"
    )
    page = context.new_page()
    page.goto("https://exemplo-com-recaptcha.com/login")

    # Interagir como humano: mover mouse, scroll, pausar
    page.mouse.move(400, 300)
    human_delay()
    page.mouse.move(600, 450, steps=20)
    human_delay(1.0, 3.0)
    page.evaluate("window.scrollBy(0, 200)")
    human_delay()

    # Preencher formulário com delays entre campos
    page.fill("#email", "qa-test@example.com")
    human_delay(0.8, 1.5)
    page.fill("#password", "senha-segura-de-teste")
    human_delay(1.0, 2.0)

    # O reCAPTCHA v3 executa automaticamente no submit
    page.click("button[type=submit]")
    human_delay(2.0, 4.0)

    # Verificar resultado
    print(page.title())
    browser.close()

Pontos críticos para manter o score alto:

• Use headless=False ou um modo headless com stealth patching. Headless puro expõe navigator.webdriver=true e ausência de window.chrome.
• Adicione ruído comportamental: movimentos de mouse com steps, pausas aleatórias, scroll progressivo. Bots que preenchem 10 campos em 200ms são trivialmente detectáveis.
• Use proxies residenciais com geo-targeting consistente: se o site é .com.br, use user-country-BR. Um IP alemão acessando um site brasileiro de e-commerce com conta em português é um sinal de anomalia.
• Mantenha cookies entre sessões: se possível, reutilize o contexto do navegador para acumular histórico. Sessões completamente limpas a cada requisição são suspeitas.
• Rotacione IPs com moderação: sticky sessions de 10-30 minutos são mais naturais que um IP novo a cada request. Veja locations do ProxyHat para cobrir geografias específicas.

Erros comuns e edge cases

1. Reutilizar tokens

Cada token é válido por aproximadamente 120 segundos e para uma única verificação. Tentar reusar um token gera timeout-or-duplicate no error-codes.

2. Ignorar o parâmetro action

Se o cliente envia action: 'submit' mas o servidor espera action: 'login', o token é válido mas o action não corresponde. Sem validação, você aceita tráfego de contexto errado.

3. Headless sem stealth

Playwright e Puppeteer em modo headless padrão expõem múltiplos sinais: navigator.webdriver, navigator.plugins.length === 0, chrome.runtime ausente. Use playwright-stealth ou puppeteer-extra-plugin-stealth, ou melhor, execute em modo visível.

4. Conflito de JA3/JA4

Mesmo com um browser real, se o tráfego passa por um proxy MITM que termina TLS (como alguns proxies corporativos), a fingerprint TLS apresentada ao Google é a do proxy, não a do browser. O ProxyHat opera como proxy HTTP/SOCKS5 sem terminação TLS, então a fingerprint do navegador é preservada.

5. Volume excessivo por IP

Mesmo IPs residenciais podem ser flaggados se o volume for anômalo. 500 requisições de login em 10 minutos do mesmo IP é um padrão de credential stuffing. Distribua tráfego entre múltiplas sessões e respeite rate limits naturais.

Onde isso é apropriado — e onde não é

Este guia é para automação legítima. Casos apropriados:

• QA de acessibilidade: testar se usuários com leitores de tela conseguem navegar em páginas protegidas por reCAPTCHA v3.
• Testes de carga autorizados: simular tráfego realista contra seu próprio ambiente de staging.
• Pesquisa de segurança com consentimento: auditorias de anti-bot em sistemas que você possui ou tem autorização explícita para testar.
• Monitoramento de SERP: ver SERP tracking e web scraping legítimo respeitando robots.txt e ToS.

Não é apropriado para: criação de contas em massa, credential stuffing, fraude de pagamento, bypass de limites de taxa em serviços de terceiros sem autorização, ou qualquer atividade que viole o Computer Fraud and Abuse Act (CFAA) nos EUA ou o GDPR na União Europeia. O reCAPTCHA v3 é uma medida de proteção; tentar evitá-lo em sistemas que você não possui pode constituir violação de lei e dos termos de serviço.

Para casos de uso legítimos, o ProxyHat oferece planos de proxies residenciais com geo-targeting em mais de 190 países. A combinação de IPs residenciais limpos, navegador real e comportamento humanizado é o que permite que automação legítima seja classificada como tráfego humano pelo motor de risco do Google.