Como o DataDome realmente detecta bots

A maioria das pessoas conhece o DataDome da mesma forma: um scraper que funcionava ontem começa a retornar 403, ou um captcha de slider aparece onde antes ficava a página. O instinto é adicionar um proxy ou trocar o user agent. Isso raramente ajuda, porque o DataDome não está olhando para nenhum sinal isolado. Ele pontua um quadro completo da requisição, e a solução é enviar um quadro que pareça real.

Veja o que ele realmente analisa.

O fingerprint do dispositivo

O JavaScript do DataDome roda na página e coleta um fingerprint do cliente: dimensões da tela e da janela, fuso horário, idioma, fontes instaladas, hashes de canvas e WebGL, a lista de codecs suportados e dezenas de sinais menores. Por si só, esse fingerprint não é um veredito. É uma identidade que o DataDome rastreia ao longo das requisições, então uma combinação inconsistente ou impossível (um user agent "Chrome no Windows" combinado com um renderizador WebGL de Linux) chama a atenção imediatamente.

TLS e ordem dos headers

Antes de qualquer JavaScript rodar, o DataDome já tem dois sinais fortes vindos da própria conexão:

• O fingerprint de TLS (JA3/JA4). As cifras e extensões exatas que seu cliente HTTP oferece raramente batem com um navegador real. Um handshake padrão de requests ou axios é trivialmente distinguível do Chrome.
• A ordem e a capitalização dos headers. Navegadores enviam os headers em uma ordem específica e estável. A maioria das bibliotecas HTTP não, e o DataDome lê essa ordem como um indício antes mesmo de ler qualquer valor de header.

É por isso que trocar apenas a string do User-Agent não muda nada. A string diz Chrome; o handshake diz Python.

As tags comportamentais

Depois que a página carrega, o DataDome envia um payload de tags comportamentais de volta ao seu endpoint de coleta: movimento do mouse, tempo de scroll, cadência de digitação, eventos de focus e blur e os intervalos entre eles. Uma sessão real produz um fluxo bagunçado, com formato humano. Um navegador headless produz nada ou algo limpo e rápido demais.

A resposta a esse payload é o que define o cookie datadome. Acerte o payload e o cookie volta em estado confiável. Erre, ou pule essa etapa, e você recebe o interstitial ou o slider.

Por que navegadores headless ainda são pegos

Rodar Puppeteer ou Playwright gera tags reais e um handshake TLS real, então passa por mais coisas do que um cliente HTTP puro. Mas é lento (segundos por sessão, centenas de MB de RAM por worker) e deixa seus próprios fingerprints: navigator.webdriver, peculiaridades de renderização específicas de headless e padrões de timing de frameworks de automação que os plugins de stealth corrigem sempre uma versão atrás. Você acaba mantendo uma fazenda de navegadores e uma esteira de plugins para brigar com um detector que atualiza mais rápido do que você consegue acompanhar.

Como se parece uma requisição aprovada

Uma requisição em que o DataDome confia carrega três coisas que concordam entre si:

1. Um cookie datadome válido em seu estado liberado.
2. O fingerprint de TLS e o conjunto de headers contra os quais o cookie foi emitido.
3. Uma requisição downstream de um IP que se encaixa na política do alvo (traga o seu próprio proxy).

A parte difícil é produzir as duas primeiras sem um navegador. É exatamente isso que fazemos: geramos o payload de tags, resolvemos a verificação de dispositivo e o slider do lado do servidor e devolvemos o cookie datadome mais o conjunto de headers contra o qual ele foi assinado. Você anexa tudo à sua própria requisição e vai direto aos dados. Sem Chrome headless, sem plugins de stealth, sem jogo de gato e rato.

Se você quiser a mecânica e um exemplo funcional, veja a página de bypass do DataDome. Se você está sendo bloqueado por outro fornecedor, a lista completa de muros cobre Akamai, Cloudflare, PerimeterX, Imperva e o resto.