Um bot simples se entrega por não executar JavaScript. Mas os anúncios já não são verificados por scripts em curl, e sim por navegadores de verdade controlados por programas. Esse navegador headless carrega a página, executa o código, espera, clica e, para uma proteção ingênua, não se diferencia de um visitante. O que ajuda a separá-lo é a impressão digital do navegador, o fingerprint, e os rastros de automação que o programa deixa no ambiente.
O que é um navegador headless
Headless quer dizer sem cabeça, ou seja, sem janela gráfica. É o mesmo motor do Chrome ou do Firefox, só que rodando em segundo plano e controlado por um programa. As ferramentas de automação mais populares (Puppeteer, Playwright, Selenium) abrem páginas, preenchem formulários, tiram screenshots e percorrem cadeias de redirecionamento.
Quem usa navegadores headless contra a sua landing:
- plataformas de anúncios: verificam a página de destino como o usuário a verá;
- spy tools: salvam landings inteiras (mais no artigo proteção contra spy tools);
- tráfego fraudulento: infla cliques e até conversões;
- scrapers da concorrência: coletam textos, preços, estrutura.
O problema principal para o filtro: o navegador headless passa no teste de execução de JavaScript. Por isso são necessários sinais mais sutis.
O que é o fingerprint do navegador
O fingerprint do navegador é o conjunto de características que o navegador revela ao site. Parte delas é enviada sozinha, parte é medida por script.
| Componente | O que é | O que pode denunciar |
|---|---|---|
| User-agent | linha com nome e versão do navegador e do sistema | versão padronizada ou desatualizada |
| Idioma e localidade | lista de idiomas do navegador | idioma que não combina com o GEO |
| Fuso horário | fuso do sistema | fuso que não combina com o país do IP |
| Tela | resolução, profundidade de cor, densidade de pixels | tamanhos redondos típicos de servidor |
| Gráficos | placa de vídeo, renderizador, detalhes de renderização | renderizador por software em vez de placa real |
| Fontes | conjunto de fontes instaladas | sistema de servidor sem nada instalado |
| Dados de hardware | núcleos, memória, tela sensível ao toque | características de desktop em um celular |
| APIs disponíveis | quais interfaces do navegador existem | falta do que um navegador real dessa versão tem |
O fingerprint é usado de duas formas. Para reconhecimento: entender que visitas diferentes vieram do mesmo aparelho. E para verificar a autenticidade: entender se esse conjunto parece um aparelho real. Para a proteção contra bots, a segunda é a que importa, e é nela que se apoia qualquer antibot para site.
Sinais de headless e de automação
A flag webdriver
Pelo padrão, um navegador controlado por programa pela interface de automação define a propriedade navigator.webdriver. É o sinal mais conhecido e o mais fácil de esconder: troca-se com uma linha. Por isso uma proteção séria não depende só dele.
Rastros de controle
As ferramentas de automação deixam no ambiente objetos, variáveis e alterações características no comportamento de algumas funções. São muitos, mudam a cada versão das ferramentas, e esconder todos de uma vez é difícil.
Incoerência com o que é declarado
O navegador headless muitas vezes se entrega por contradições:
- o user-agent diz Chrome no Windows, mas o conjunto de APIs é o de uma versão headless no Linux;
- declara ser iPhone, mas suporta interfaces que o Safari não tem;
- a tela é de celular, mas não há entrada por toque;
- a placa de vídeo aparece como renderizador por software, típico de servidores.
Ambiente de servidor
Conjunto mínimo de fontes, ausência de dispositivos de mídia, resolução redonda, valores de hardware pouco naturais: tudo isso indica um navegador rodando em servidor, sem usuário real.
Tempo e comportamento
O programa age instantaneamente ou com pausas sempre iguais. Não há movimento de mouse, toques ou rolagem, ou eles são perfeitamente regulares. Um tempo na página falsificado também pode ser percebido: quando o que o script informa não bate com os tempos reais.
Dica. Nenhum sinal desta lista prova sozinho que é bot. O que prova é a combinação: três ou quatro contradições independentes na mesma visita quase nunca aparecem em navegadores reais.
Navegadores antidetect: onde fica o limite
O navegador antidetect troca o fingerprint para que cada perfil pareça um aparelho real separado. No marketing de afiliados, é uma ferramenta comum de trabalho: media buyers mantêm nele as contas de anúncio para que a plataforma não as associe.
Para o filtro de tráfego, é importante separar dois casos:
- antidetect controlado por uma pessoa: para a landing, é na prática um visitante comum; a pessoa mexe o mouse, lê, clica;
- antidetect controlado por um programa: a mesma automação, só que mais bem disfarçada; ela se entrega pela incoerência da falsificação e pelo comportamento.
Ou seja, o fingerprint não é a única linha de defesa. Um bot bem disfarçado se entrega pelo que faz, não pela aparência.
Falsos positivos: navegadores internos e WebView
O erro mais comum na filtragem por fingerprint é barrar os navegadores internos dos apps. Facebook, Instagram e TikTok abrem links em um navegador interno baseado em WebView. Ele tem:
- user-agent incomum, com o nome do app;
- recursos limitados em comparação com um navegador completo;
- sinais que coincidem com rastros de automação;
- muitas vezes, referrer perdido.
Ao mesmo tempo, é justamente pelos navegadores internos que chega a maior parte do tráfego real das redes sociais. Por isso um sinal de automação no WebView não pode ser lido como bot evidente, só como um dos sinais na avaliação geral. Como o identificador de clique da plataforma ajuda a separar essa visita de um bot está no artigo fbclid, gclid, ttclid.
Como funciona a verificação do navegador no ArtisanClo
No ArtisanClo, a verificação do navegador é uma etapa própria, depois das verificações de rede. O script roda no navegador do visitante e informa o que encontrou; a página fica oculta até a decisão chegar. Alguns interruptores de proteção cuidam disso:
- Bloquear headless: pega bots e autoclickers que fingem ser navegador. Com rastros claros de automação, barra na hora; no log o motivo é Navegador headless detectado.
- Exigir JS: o visitante sem JavaScript recebe uma penalidade forte e é enviado para verificação. Bots simples e scrapers tropeçam aqui.
- Verificação de interação real: observa como o mouse e o dedo se movem; a pessoa se comporta de forma natural, o bot não. Acrescenta uma pequena espera, por isso é ligada para plataformas rigorosas.
- Tempo mínimo na página: o visitante que ficou menos que o tempo definido vai para a página de espera e é verificado de novo.
Os navegadores internos do Facebook, Instagram e TikTok e o WebView dos apps são reconhecidos à parte: o sinal de automação neles não barra a visita na hora, e sim entra na pontuação de confiança junto com a rede, o tempo e o referrer. Para campanhas em que quase todo o tráfego vem do navegador interno, o rigor recomendado é Equilibrado.
Navegadores-robô com sinais comprovados e tempo na página falsificado entram na lista geral de bots na primeira vez: a próxima visita desse endereço, em qualquer fluxo de qualquer cliente, recebe a White Page na hora.
Nas estatísticas, as recusas dessa etapa aparecem na parcela Verificação do navegador, e as visitas que não executaram o script e não voltaram, em A verificação não voltou. Se o que cresce é justamente a Verificação do navegador, é sinal para revisar o rigor: é nessa etapa que o filtro mais erra.
A verificação do navegador funciona com a conexão por tag JS e por arquivo PHP. A diferença entre os métodos está no artigo como instalar o cloaker no site, e a lista completa de verificações, na página de recursos.
Como montar a proteção contra headless: passos práticos
- Comece pela rede. A maioria dos bots headless roda em servidores; bloquear data centers os corta antes da verificação do navegador. Veja VPN, proxy e IPs de data center.
- Exija JavaScript onde for seguro. Se a plataforma envia o identificador de clique e o tráfego vem de navegadores comuns, exigir JS corta scrapers sem perdas.
- Ligue o bloqueio de headless em todos os fluxos.
- Deixe a verificação de interação real para tráfego caro e fontes com muita automação avançada.
- Não aperte os navegadores internos. Para redes sociais, não ligue regras rígidas desnecessárias.
- Olhe os motivos. Se Navegador headless detectado dispara em massa no tráfego mobile de uma plataforma, é motivo para investigar, não para comemorar.
A lógica geral da proteção em camadas está no artigo como filtrar bots, e a lista de sinais típicos, no material tráfego de bots: sinais.
Fingerprint do navegador e privacidade: o que saber
A palavra fingerprint costuma ser associada a vigilância: sistemas de anúncios usam impressões digitais para reconhecer o usuário sem cookie. No antifraude, a tarefa é outra. O filtro não precisa saber quem é o visitante; precisa entender se o navegador é real e se ele se comporta como uma pessoa. Por isso, na proteção contra bots, o que importa não são identificadores únicos, e sim a coerência das características entre si.
Daí uma consequência prática. Os navegadores aos poucos limitam o que pode ser medido por script: acrescentam ruído na renderização, padronizam o user-agent, escondem detalhes do hardware. Para reconhecer usuários isso é um problema; para verificar autenticidade, um problema menor: as contradições entre o declarado e o real continuam lá. Já uma proteção baseada em um ou dois sinais mágicos deixa de funcionar com o tempo, e esse é mais um argumento a favor da avaliação pela soma de sinais.
Exemplo: como fica a análise de uma visita suspeita
Digamos que no log haja uma visita com motivo ligado à automação do navegador. No cartão do clique aparece:
- rede: hospedagem em nuvem;
- navegador declarado como Chrome recente, aparelho computador;
- sem identificador de clique de anúncio;
- a verificação do navegador voltou com sinais de controle por programa.
Aqui tudo se encaixa: rede de servidor, nenhum acesso por anúncio, rastros de automação. É o clássico robô de verificação ou spy tool.
Agora outra visita: operadora móvel, navegador interno de rede social, identificador de clique presente, sinal de automação fraco. Essa visita não pode ser barrada por um único sinal; provavelmente é uma pessoa comum que abriu o anúncio no app.
A diferença entre essas duas visitas é a essência da avaliação pela soma de sinais: na primeira, vários sinais independentes se contradizem; na segunda, só um, e ainda explicado pelas particularidades do navegador interno. Se no log houver muitas visitas do segundo tipo indo para a White Page, diminua o rigor para essa plataforma.
Resumo
O navegador headless passa nas verificações simples, mas deixa rastros: flags e objetos de automação, contradições no fingerprint, ambiente de servidor, comportamento pouco natural. O fingerprint do navegador ajuda a entender se a visita parece um aparelho real, e as verificações comportamentais, se ela se comporta como uma pessoa. A regra principal é a mesma de todo o antifraude: quem decide é a combinação de sinais, não um só; caso contrário, junto com os bots vai embora o tráfego dos navegadores internos das redes sociais.
