Proteção anti-scraping: como funcionam os sistemas anti-bot modernos

O web scraping é a coleta automatizada de dados de sites: preços da concorrência, conteúdo, contatos, anúncios, estoque. Em si é legal quando se trata de dados de acesso público, mas se torna um problema quando sobrecarrega a infraestrutura, rouba conteúdo original, alimenta o dumping ou serve para preparar fraudes (ataques de força bruta contra contas, açambarcamento de produtos escassos). Segundo diferentes estimativas, o tráfego automatizado representa hoje cerca de metade de todo o tráfego da internet, por isso a proteção contra o scraping indesejado se tornou uma indústria própria.

A ideia central sobre a qual se apoia toda a proteção moderna: é possível distinguir um programa de uma pessoa, e um cliente automatizado de outro, mesmo antes de o servidor entregar um único byte de conteúdo. A decisão de bloqueio muitas vezes é tomada nos primeiros milissegundos da conexão. A seguir — o que exatamente é monitorado, com quais métodos os sites se defendem, no que convém prestar atenção, como os scrapers driblam as restrições e quais soluções já existem no mercado.

Quais parâmetros são monitorados

Os sistemas modernos não confiam em um único indício. Reúnem dezenas de sinais em diferentes níveis da pilha de rede e os condensam em uma única «pontuação de confiança» (trust score / bot score). Quanto mais baixa a pontuação, maior a probabilidade de receber um captcha, uma lentidão ou um bloqueio. Em linhas gerais, os sinais se distribuem em várias camadas.

1. Nível de rede e IP

A camada mais básica. Analisa-se a reputação do endereço IP, sua origem (ASN) e o tipo de rede. As requisições vindas de data centers da AWS, GCP ou Azure se destacam na hora — os usuários comuns não navegam assim. Monitoram-se a frequência e o ritmo das requisições de um mesmo endereço (rate limiting), os picos bruscos e os acessos a URLs atípicas. Os bons sistemas mantêm suas próprias bases de IPs «sujos», flagrados cometendo abusos em toda a sua rede.

2. Impressão digital TLS (JA3 / JA4 / JA4+)

Um dos sinais mais confiáveis e mais difíceis de falsificar, porque opera no nível de rede — antes de qualquer execução de JavaScript. Ao estabelecer a conexão HTTPS, o cliente envia uma mensagem ClientHello na qual lista as cifras, as extensões, as curvas elípticas, as versões de protocolo e os valores ALPN que suporta — em uma ordem estritamente definida. Esse conjunto é transformado por hash em uma impressão digital curta:

• JA3 (2017) — o método clássico, um hash MD5 dos campos do ClientHello. O problema: o TLS 1.3 introduziu os valores aleatórios GREASE, que fazem o hash «oscilar» de uma requisição para outra.
• JA4 / JA4+ (FoxIO, 2023) — o substituto moderno: ordena as extensões alfabeticamente e elimina o GREASE, de modo que a impressão digital se mantém estável mesmo com a ordem aleatorizada. O JA4+ é uma família de impressões digitais (incluindo a resposta do servidor JA4S, HTTP/2, etc.).

A principal força do método é a verificação de coerência: se o User-Agent afirma ser o Chrome 120 mas a impressão digital TLS corresponde à biblioteca requests do Python ou ao curl, o cliente é bloqueado na hora. A isso somam-se as impressões digitais de HTTP/2 (ordem e valores dos frames SETTINGS, priorização) e dos parâmetros de transporte de HTTP/3 (QUIC). A tendência recente é levar em conta as assinaturas pós-quânticas e as novas extensões TLS que aparecem nas compilações atuais do Chromium.

3. Cabeçalhos HTTP

Não se verificam apenas os valores em si, mas também sua composição, sua ordem e sua coerência mútua:

• o User-Agent e sua correspondência com o comportamento real do cliente;
• a presença e a correção de Accept, Accept-Language, Accept-Encoding, Referer;
• os Client Hints modernos (Sec-CH-UA, plataforma, condição mobile);
• a ordem dos cabeçalhos — cada navegador tem a sua, própria e estável.

Que a configuração regional do cabeçalho Accept-Language não coincida com o país do IP de saída — é um motivo frequente de suspeita.

4. Impressão digital do navegador

Se o cliente executa JavaScript, o site monta uma «impressão digital do dispositivo» a partir de centenas de características:

• Canvas fingerprint — o resultado de renderizar uma imagem oculta, único para a combinação GPU/driver/SO;
• WebGL / WebGPU — revelam o modelo da placa de vídeo e a versão do driver;
• AudioContext — microdiferenças no processamento do sinal de áudio;
• a lista de fontes instaladas, a resolução e os parâmetros da tela, o fuso horário, o idioma;
• as propriedades do objeto navigator, os plugins, as APIs disponíveis.

E, de novo, o essencial é a coerência. Se o Canvas é renderizado como se fosse uma GPU dedicada potente, mas o WebGL informa uma placa integrada Intel — é uma configuração «impossível», um sinal de alerta imediato. Os sistemas também verificam se a impressão digital muda com frequência demais (indício de aleatorização) ou se é estática demais entre sessões (indício de falsificação).

5. Indícios de automação

Marcadores diretos de navegadores headless e de ferramentas de automação: a flag navigator.webdriver, vestígios do protocolo CDP (Chrome DevTools Protocol), plugins e APIs ausentes, renderização por software (SwiftShader) em vez de uma GPU por hardware, tamanhos de janela atípicos. A geração rápida demais da impressão digital Canvas (mais rápida do que um navegador real conseguiria) — também é um sinal.

6. Biometria comportamental

A camada mais «humana», que cada vez mais decide o resultado. Os modelos de ML analisam como o visitante interage com a página: as trajetórias do mouse, o ritmo e a velocidade do scroll, as pausas, o ritmo das teclas e da digitação, a sequência de navegação. Uma pessoa real move o cursor de forma caótica, rola a página de maneira irregular e às vezes erra o alvo. Um bot se move em linhas retas, rola a página em velocidade constante e não erra. A ausência total de movimentos do mouse durante a navegação — já é suspeita por si só.

Quais métodos de proteção existem

A proteção é construída como um bolo de camadas: cada nível filtra uma parte do tráfego indesejado e, no conjunto, elevam o custo do ataque. Principais abordagens:

Rate limiting e throttling. Limitar o número de requisições por IP/sessão e unidade de tempo, e desacelerar quando os limites são ultrapassados. Uma camada base simples, mas imprescindível.

robots.txt. Um arquivo declarativo que indica quais seções cada bot pode rastrear. Só funciona com os rastreadores «honestos»: um bot que age de boa-fé o respeita; um mal-intencionado — o ignora. É uma ferramenta de acordo, não de coação. Segundo dados da Cloudflare, apenas cerca de um terço dos domínios mais importantes tem robots.txt.

WAF e listas de reputação. O firewall de aplicações web bloqueia padrões maliciosos conhecidos e o tráfego proveniente de IPs/ASN com má reputação.

CAPTCHA e scoring invisível. A evolução foi do texto distorcido e da seleção de imagens («semáforos», «faixas de pedestres») aos sistemas invisíveis que avaliam o comportamento em segundo plano sem dizer nada (reCAPTCHA v3, Cloudflare Turnstile, hCaptcha). O challenge visível agora — já é a consequência de uma pontuação de confiança baixa, não a primeira linha.

Proof-of-work (prova de trabalho). O navegador resolve, sem que se perceba, um problema criptográfico. Para um usuário real é gratuito, mas para a automação em grande escala gera um custo de computação assimétrico que torna o ataque economicamente inviável. Essa abordagem é a base do Kasada e do Friendly Captcha.

Challenges de JavaScript. O servidor entrega um script que precisa ser executado em um ambiente de navegador completo; os clientes HTTP sem motor de JS ficam de fora.

Fingerprinting + scoring com ML. Coleta de todos os sinais anteriores e sua avaliação por meio de modelos de aprendizado de máquina em tempo real. Os sistemas mais avançados mantêm milhares de modelos treinados para sites específicos.

Honeypots e armadilhas. Links e campos invisíveis para uma pessoa aos quais só os bots reagem. A evolução da ideia — os «labirintos» e os tarpits: páginas isca geradas sem fim nas quais os infratores ficam presos e desperdiçam recursos (os links são marcados com nofollow para não prejudicar o SEO).

Ofuscação dinâmica e polimorfismo. Mudar constantemente a marcação, os nomes das classes, a estrutura das respostas e o próprio código de proteção para que os scrapers não consigam «se fixar» a um modelo específico e para que os atacantes não possam fazer engenharia reversa da proteção de uma vez por todas.

Implantação no edge ou do lado da aplicação. A proteção no edge (na CDN) pega os bots mais cedo, antes de chegarem ao servidor de origem, e reduz a carga. A proteção em nível de aplicação enxerga mais contexto de negócio e pode aplicar a lógica de cenários específicos. As grandes empresas costumam usar as duas camadas.

Verificação de bots «bons» e agent trust. Mecanismos que permitem aos rastreadores legítimos (buscadores, monitoramento) se autenticarem para não serem bloqueados. Uma linha recente — os padrões com os quais os agentes de IA podem se identificar e declarar suas intenções (treinamento, inferência, busca), e o dono do site — decidir quem deixa passar.

No que prestar atenção ao montar a proteção

Alguns princípios práticos que distinguem uma proteção que funciona de uma meramente formal:

Múltiplas camadas. Um único sinal não é confiável. Um IP residencial não salva ninguém se a impressão digital TLS grita «Python» e o navigator.webdriver denuncia a automação. A força está na verificação cruzada da coerência de muitas camadas ao mesmo tempo.

Equilíbrio com os falsos positivos (false positives). Uma proteção agressiva demais atinge os usuários reais: pessoas atrás de um NAT corporativo, uma VPN, em modo privado ou com um navegador incomum podem parecer suspeitas. Um comprador bloqueado — é uma conversão perdida e mais tickets de suporte. A qualidade de uma solução se mede em boa parte justamente por um FPR baixo (False Positive Rate — a proporção de falsos positivos, ou seja, a porcentagem de usuários reais tomados por bots por engano).

Não bloquear os bots úteis. O Googlebot, o Bingbot, o monitoramento e os bots de pré-visualização das redes sociais devem passar. Por isso são necessárias listas de permitidos e verificação. Bloquear totalmente os rastreadores de IA, aliás, torna o site invisível para a busca com IA (ChatGPT, Perplexity, etc.) — é uma decisão de negócio, não só técnica.

Proteção específica da API e dos endpoints mobile. Muitas vezes os dados não são extraídos das páginas, e sim diretamente da API, onde não há impressão digital de navegador. Para os aplicativos móveis, usam-se a attestation do dispositivo e os SDKs móveis.

Priorizar o mais valioso. Convém reforçar a proteção nos pontos mais valiosos e mais atacados — listas de preços, busca, fichas de produto, login, checkout — em vez de espalhar verificações pesadas por todo o site.

Monitoramento e atualização. É uma corrida armamentista. Os fornecedores anti-bot atualizam a detecção toda semana; uma proteção configurada «uma única vez» fica obsoleta. São necessários painéis de análise do tráfego de bots e uma revisão periódica das regras.

Como os scrapers driblam as restrições

Entender o lado do ataque é útil — mostra contra o que exatamente a proteção é construída. O scraping profissional hoje não é «trocar o User-Agent», mas imitar de forma coerente um cliente real em todas as camadas ao mesmo tempo.

Rotação de proxies. Os IPs de data center são baratos, mas se detectam com facilidade. Os proxies residenciais encaminham o tráfego por redes domésticas reais e parecem usuários comuns; os proxies móveis são ainda mais confiáveis, mas mais caros. Os IPs são rotacionados entre requisições, escolhendo a geolocalização conforme o público-alvo do site. Mas trocar de IP por si só não adianta nada — não corrige a impressão digital TLS nem a impressão digital do navegador.

Impersonação TLS. Bibliotecas como curl-impersonate e curl_cffi reproduzem a pilha TLS de um navegador real para que o JA3/JA4 coincida com o User-Agent declarado. O princípio-chave dos atacantes — não tentar parecer «melhor» que um navegador, mas ser o mais coerente possível com ele: qualquer incongruência entre camadas é pior do que uma impressão digital «comum».

Navegadores headless reforçados (fortified). Um Selenium/Puppeteer puros se entregam pelas flags de automação. Por isso se usam: - nodriver e undetected-chromedriver — eliminam os vestígios de WebDriver e não usam o protocolo clássico; - SeleniumBase nos modos UC/CDP; - Camoufox — um navegador antidetecção baseado no Firefox com injeção da impressão digital em nível de C++; - plugins stealth para Puppeteer/Playwright (embora fiquem atrás das atualizações da detecção e com o tempo «expirem»).

Você encontrará uma análise detalhada e uma comparação dessas ferramentas no artigo 11 Best Anti-Bot Bypass Tools for Web Scraping.

Navegadores antidetecção. Multilogin, GoLogin, NestBrowser, AdsPower e similares criam perfis isolados com impressões digitais únicas, porém coerentes (Canvas, WebGL, fontes) — pensados na origem para o gerenciamento de múltiplas contas, mas muito usados também no scraping.

Imitação do comportamento. Atrasos aleatórios, trajetórias do mouse «humanas», scroll irregular, pausas, navegação de aquecimento antes da ação-alvo — para superar a análise de comportamento.

Resolução de captchas. Serviços como 2Captcha, Anti-Captcha ou CapSolver devolvem um token para reCAPTCHA, hCaptcha ou Turnstile (da ordem de $1--2 por 1000 resoluções). Mas custa tempo e dinheiro, então os profissionais apostam na prevenção — não deixar a pontuação de confiança cair até o ponto em que o captcha aparece.

Serviços gerenciados. As scraping APIs prontas (Scrapfly, Bright Data Web Unlocker, ScraperAPI, Scrapeless) assumem toda a complexidade: uma única pilha de Chrome com patches, rotação de proxies residenciais, ajuste de TLS/HTTP/2/Canvas às compilações reais do navegador e resolução de challenges. Para o atacante, isso transfere ao fornecedor o ônus de sustentar a «corrida armamentista».

A conclusão principal é a mesma para os dois lados: não vence quem se disfarça de forma mais agressiva, e sim quem tem todas as camadas coerentes entre si. É justamente na busca por incongruências que se baseia a detecção.

Quais soluções existem

O mercado de bot management é maduro e muito povoado. A seguir — os principais players. Os preços quase sempre são personalizados (enterprise), então convém consultar os valores concretos com os fornecedores; as referências apresentadas vêm de dados públicos e têm caráter orientativo.

Cloudflare Bot Management. Faz parte da maior plataforma de CDN/segurança do mundo, que atende cerca de 20 % da web. Usa ML e análise de comportamento treinados com dados de dezenas de milhões de sites, o que lhe dá uma enorme visibilidade de rede. No seu ecossistema entram o Turnstile (captcha invisível), o Bot Analytics e também as linhas de IA mais recentes: bloqueio de rastreadores de IA (desde julho de 2025 — por padrão nos domínios novos, «Content Independence Day»), gerenciamento via AI Crawl Control, controle do cumprimento do robots.txt, um «labirinto» para os infratores e o marketplace Pay Per Crawl, onde os editores podem cobrar das empresas de IA pelo rastreamento (resposta 402 Payment Required). O gerenciamento de bots básico está disponível a partir dos planos pagos; os recursos completos — em Business/Enterprise. Sua maior força é fazer parte da plataforma global da Cloudflare.

DataDome. Um dos líderes do mercado, voltado para o e-commerce, os marketplaces, as viagens, a fintech e a mídia. Aposta no ML em tempo real: segundo dados públicos, mantém dezenas de milhares de modelos para clientes específicos. Seus pontos fortes — a proteção de API e de aplicativos móveis (attestation do dispositivo, SDKs móveis), um percentual baixo de falsos positivos graças à combinação de sinais de comportamento e de contexto, e modos de resposta flexíveis, de challenges «suaves» até o bloqueio taxativo. Os usuários o avaliam de forma consistente pela facilidade de implantação. Segundo as referências públicas, os orçamentos começam em torno de $2000--4000/mês para um tráfego moderado e chegam a $12 000--25 000/mês ou mais em grandes projetos multirregionais.

HUMAN (ex-PerimeterX, fundida com a HUMAN Security). Forte em análise de comportamento e em seu ecossistema antifraude: proteção contra o açambarcamento de produtos escassos (bots scalper), o credential stuffing e o roubo de contas. Uma boa opção quando é preciso unir anti-bot e antifraude com relatórios avançados e uma analítica madura.

Akamai Bot Manager. Um peso-pesado corporativo para tráfego grande e de alta carga. Opera no edge por meio do Akamai Intelligent Edge, usa análise de comportamento, ML e inteligência de ameaças global, oferece políticas granulares (block / challenge / atraso / entrega de conteúdo alternativo) e separa os bots «bons» dos «maus». Faz mais sentido para quem já está sobre a pilha da Akamai.

Imperva Advanced Bot Protection. Uma solução madura com uma forte proteção de API e boa analítica; muitas vezes é avaliada junto com o WAF da Imperva como uma proteção corporativa integral de aplicações.

Kasada. Aposta nos challenges criptográficos de proof-of-work e na ofuscação dinâmica: o objetivo — disparar o custo do ataque para os bots headless e os emuladores, e fazê-lo sem captchas visíveis (mínimo atrito para as pessoas). É especialmente eficaz contra os bots que já aprenderam a driblar a detecção imitando o comportamento, e contra a emulação/automação. Bom para equipes que se importam com a resistência ao reequipamento constante dos atacantes.

Arkose Labs. Combina o scoring de risco com challenges interativos e a abordagem de «tornar o ataque não lucrativo»; forte em cenários de proteção contra a fraude e o cadastro massivo de contas falsas.

Netacea. Abordagem agentless: é implantado do lado do servidor/edge sem JS de cliente nem SDK, por isso é invisível para os atacantes. Usa analítica de intenção (avalia a intenção, não as assinaturas) e integração com SIEM/SOAR.

Fastly Bot Management. Proteção no edge contra ATO, scraping, DDoS de camada de aplicação, credential stuffing e abuso da lógica de negócio — uma escolha lógica para quem já está na Fastly.

Fornecedores de CAPTCHA como camada à parte. Google reCAPTCHA (v2 — caixa de seleção com recurso a imagens; v3 — scoring invisível sem interação), hCaptcha (não atrelado ao ecossistema do Google), Cloudflare Turnstile (verificações em segundo plano sem challenge visível na maioria dos casos), Friendly Captcha (proof-of-work). Integram-se tanto por conta própria quanto dentro de plataformas de bot management maiores.

Em linhas gerais, o mercado pode ser dividido assim: Cloudflare, Akamai e Fastly — fortes no edge e para consolidar a segurança web em uma única pilha; DataDome e HUMAN — mais a fundo na camada de aplicação, na API e no mobile; Kasada e Arkose — focados em encarecer o ataque de forma assimétrica; Imperva e Netacea — proteção corporativa madura de aplicações e API.

Para onde o mercado caminha

A proteção anti-scraping — é uma corrida armamentista sem fim na qual os dois lados evoluem lado a lado. Algumas tendências em destaque:

• Deslocamento das assinaturas rumo ao comportamento e ao ML. A detecção se apoia cada vez menos em regras estáticas e cada vez mais — na biometria comportamental e em modelos treinados para um site específico.
• Os sinais de rede como alicerce. As impressões digitais de TLS/HTTP-2/HTTP-3 são difíceis de falsificar e agem antes do JS, por isso continuam sendo a camada base e mais confiável; surgem sinais novos como o TLS pós-quântico.
• Challenges «suaves» e proof-of-work em vez dos captchas incômodos — para não quebrar a experiência de usuário das pessoas reais.
• Os rastreadores de IA como categoria nova. O surgimento da monetização (pay-per-crawl), de padrões de identificação de bots e do conceito de «agent trust»: a pergunta passa de «pessoa ou bot?» para «a qual bot e com que finalidade permitimos o acesso?».
• A attestation de dispositivos e as raízes de confiança por hardware — sobretudo em cenários móveis.

Não existe proteção perfeita: um scraper suficientemente motivado e financiado, com proxies residenciais, uma pilha de navegador com patches e resolvedores de captchas, vai superar quase qualquer barreira. O objetivo realista da proteção — não é tornar o scraping impossível, mas torná-lo tão caro, lento e frágil que deixe de ser rentável, sem por isso afetar os usuários reais nem os bots úteis.