Entendendo o PerimeterX (HUMAN Security): Detecção, Sinais e Mitigação Legítima

Se você já tentou automatizar coleta de dados em sites de companhias aéreas ou e-commerce de luxo e encontrou uma página de bloqueio com a mensagem "Press & Hold" ou um desafio interativo, você esbarrou no PerimeterX — agora parte da HUMAN Security. Entendendo o PerimeterX (HUMAN) em profundidade, é possível construir automação legítima que passa por seus desafios sem disparar falsos positivos, respeitando os termos de serviço do site alvo.

Este guia técnico cobre a arquitetura do PerimeterX, seus sinais de detecção — incluindo cookies _px3/_pxhd, fingerprinting de Canvas/WebGL, assinaturas TLS/JA3, reputação de IP e análise comportamental — e como combinar proxies residenciais com browser stealth para automação legítima e sustentável.

O que é PerimeterX (HUMAN Security) e como funciona

O PerimeterX foi fundado em 2014 e adquirido/rebatizado como HUMAN Security em 2021. É uma das principais plataformas de bot management do mercado, competindo diretamente com DataDome, Akamai Bot Manager e Imperva. A HUMAN Security processa bilhões de requisições por dia para clientes como United Airlines, American Airlines, Neiman Marcus e Saks Fifth Avenue.

A arquitetura do PerimeterX opera em três camadas principais:

• Edge/CDN layer: O JavaScript do PerimeterX é injetado nas páginas do site alvo via snippet ou integração com CDN (Cloudflare, Akamai, AWS CloudFront). Este JS coleta sinais do navegador em tempo real.
• Decision engine: Os sinais coletados são enviados para a API do PerimeterX, que retorna um veredito (allow, challenge, block) em milissegundos.
• Challenge layer: Se o veredito for "challenge", o usuário recebe um CAPTCHA interativo (Press & Hold) ou um bloco JavaScript silencioso que tenta provar que o cliente é um navegador real.

Os cookies _px3 e _pxhd

O PerimeterX usa dois cookies principais para rastrear e validar sessões:

• _px3: Cookie de sessão principal, gerado pelo JavaScript do PerimeterX após a primeira carga de página. Contém um token criptografado que codifica o score de risco, timestamp, sinais de fingerprinting e um HMAC assinado com a chave do cliente. Este cookie é validado no backend a cada requisição.
• _pxhd: Cookie de persistência de longo prazo, usado para identificar usuários recorrentes. É renovado periodicamente e ajuda o PerimeterX a construir um perfil comportamental ao longo do tempo.

Quando o _px3 expira ou é invalidado, o JavaScript do PerimeterX executa um challenge silencioso — uma sequência de operações criptográficas (frequentemente baseadas em PBKDF2 ou similar) que prova que o cliente pode executar JavaScript real com timing esperado. Bots headless que não executam JS adequadamente falham neste challenge.

O _px3 é o coração do PerimeterX. Sem um token válido, mesmo requisições com proxy residencial perfeito serão bloqueadas. O segredo está em manter uma sessão de navegador real que gera e renova esse cookie naturalmente.

Sinais de detecção do PerimeterX

A detecção PerimeterX combina dezenas de sinais em um modelo de scoring. Vamos detalhar os principais:

1. Fingerprinting de dispositivo

O JavaScript do PerimeterX coleta uma ampla variedade de sinais de fingerprinting:

• Canvas fingerprint: Renderiza texto/shapes em um canvas off-screen e computa o hash do resultado. Variações sutis na renderização (anti-aliasing, subpixel rendering, driver de GPU) produzem hashes diferentes entre dispositivos reais e headless. O Playwright headless com Chromium padrão produz um canvas hash que é trivialmente distinguível de um Chrome real.
• WebGL fingerprint: Coleta WEBGL_debug_renderer_info (vendor e renderer), parâmetros de extensões WebGL e precisão de shaders. Headless browsers frequentemente reportam "SwiftShader" ou "Google Inc." como renderer, o que é uma flag imediata.
• Screen metrics: Resolução de tela, devicePixelRatio, availWidth/availHeight (que excluem taskbar em desktops reais), colorDepth. Valores inconsistentes — como screen.width = 0 em alguns headless — são detectados.
• Navigator properties: navigator.platform, navigator.hardwareConcurrency, navigator.deviceMemory, navigator.languages, navigator.plugins. Inconsistências entre user-agent e platform (ex: UA diz Windows mas platform diz Linux) são flags.
• Audio fingerprint: Usa a Web Audio API para gerar um fingerprint baseado em processamento de sinal. Diferenças na implementação de DSP entre browsers reais e headless produzem hashes distintos.

2. TLS/JA3 fingerprinting

O PerimeterX inspeciona a assinatura TLS do cliente (JA3/JA4) no handshake. O JA3 é um hash MD5 que combina versão TLS, cipher suites oferecidas, extensões e curvas elípticas, na ordem exata enviada pelo cliente. Cada biblioteca HTTP (requests, aiohttp, Go http.Client) e cada browser produzem JA3 diferentes.

Por exemplo, um curl padrão produz um JA3 como 771,4865-4866-4867-49195-49199-..., enquanto Chrome 120 produz algo como 771,4865-4866-4867-49195-49199-49162-49161-... com extensões específicas. O PerimeterX mantém uma base de dados de JA3 conhecidos e bloqueia assinaturas associadas a bibliotecas HTTP comuns.

Para mais detalhes sobre JA3, consulte a documentação original do JA3 pela Salesforce.

3. Reputação de IP

O PerimeterX mantém uma base de dados de reputação de IP em tempo real, integrada com feeds de ameaças como Spamhaus e dados próprios. IPs de datacenter (AWS, GCP, Azure, DigitalOcean, OVH) recebem scores de risco significativamente mais altos que IPs residenciais. O PerimeterX também analisa:

• ASN do IP (Autonomous System Number) — ISPs residenciais como Comcast, AT&T, Telefónica têm scores baixos; ASNs de datacenter têm scores altos.
• Histórico do IP — se o IP foi flaggado em ataques anteriores ou aparece em listas de proxy/SOCKS conhecidas.
• Geolocalização vs. timezone do navegador — se o IP está em Frankfurt mas o browser reporta timezone America/New_York, isso é uma flag.
• Velocidade de requisições por IP — burst de 100+ requisições em 1 segundo de um único IP é suspeito.

4. Análise comportamental

Este é o diferencial do PerimeterX em relação a concorrentes como DataDome. O PerimeterX é significativamente mais pesado em sinais comportamentais:

• Movimento de mouse: O JS do PerimeterX registra eventos mousemove com timestamp preciso. Movimentos perfeitamente lineares, ausência de micro-tremores, ou zero eventos de mouse antes de um clique são flags fortíssimas.
• Timing de digitação: Intervalos entre keydown/keyup são analisados. Digitação com intervalos perfeitamente uniformes (ex: exatamente 50ms entre cada tecla) é detectada como automação.
• Scroll patterns: Velocidade de scroll, aceleração e desaceleração. Scroll instantâneo para o fim da página é suspeito.
• Sequência de interação: Um humano típico carrega a página, espera 1-3 segundos, move o mouse, talvez scroll, depois clica. Um bot que carrega a página e clica em um botão em 50ms é detectado.
• Touch events (mobile): Em dispositivos móveis, o PerimeterX analisa touchstart, touchmove, touchend com pressão, área de toque e duração.

PerimeterX vs DataDome vs Akamai

Cada solução anti-bot tem uma "personalidade" de detecção diferente. Entender essas diferenças ajuda a escolher a estratégia de mitigação correta:

A principal diferença prática: contra DataDome, proxies residenciais com bom fingerprinting de device resolvem a maioria dos casos. Contra PerimeterX, você também precisa simular comportamento humano — mouse movement, delays, pacing. Contra Akamai, o sensor _abck é tão complexo que a maioria dos scrapers opta por não tentar bypass direto.

Mitigação concreta: bypass PerimeterX legitimamente

Para automação legítima — como pesquisa de preços autorizada, auditoria de segurança, ou coleta de dados públicos dentro dos termos de serviço — a estratégia contra PerimeterX combina quatro pilares:

1. Proxy residencial com geolocalização consistente
2. Browser stealth com fingerprinting realista
3. Contexto de navegador coerente (timezone, idioma, viewport)
4. Pacing humano com delays aleatórios e simulação de mouse

Passo 1: Configurar proxy residencial com ProxyHat

Use proxies residenciais com geo-targeting por país e cidade para garantir que o ASN, geolocalização e timezone do navegador sejam consistentes:

# Proxy residencial HTTP com geo-targeting EUA
export HTTP_PROXY="http://user-country-US:pass@gate.proxyhat.com:8080"

# Proxy residencial com cidade específica (Nova York)
export HTTP_PROXY="http://user-country-US-region-new_york-city-new_york_city:pass@gate.proxyhat.com:8080"

# Sessão sticky para manter o mesmo IP durante a sessão
export HTTP_PROXY="http://user-sid-myflight001-country-US:pass@gate.proxyhat.com:8080"

# Testar com curl
curl --proxy "$HTTP_PROXY" https://httpbin.org/ip

Passo 2: Playwright com stealth e contexto realista

O Playwright com playwright-extra e puppeteer-extra-plugin-stealth é a combinação mais eficaz para passar pelos challenges JS do PerimeterX:

from playwright.sync_api import sync_playwright
import time
import random

PROXY = "http://user-sid-flight01-country-US-region-new_york-city-new_york_city:pass@gate.proxyhat.com:8080"

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # headless=False é mais confiável contra PerimeterX
        proxy={"server": PROXY},
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-sandbox",
            "--disable-web-security",
        ]
    )

    context = browser.new_context(
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        timezone_id="America/New_York",
        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",
        extra_http_headers={
            "Accept-Language": "en-US,en;q=0.9",
            "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
        }
    )

    # Injetar scripts stealth antes da página carregar
    context.add_init_script("""
        // Ocultar webdriver flag
        Object.defineProperty(navigator, 'webdriver', {get: () => undefined});
        // Sobrescrever plugins para parecer Chrome real
        Object.defineProperty(navigator, 'plugins', {
            get: () => [1, 2, 3, 4, 5],
        });
        // WebGL renderer realista
        const getParameter = WebGLRenderingContext.prototype.getParameter;
        WebGLRenderingContext.prototype.getParameter = function(param) {
            if (param === 37445) return 'Intel Inc.';
            if (param === 37446) return 'Intel Iris OpenGL Engine';
            return getParameter.call(this, param);
        };
    """)

    page = context.new_page()

    # Navegar com delay realista
    page.goto("https://www.united.com/", wait_until="domcontentloaded")
    time.sleep(random.uniform(2.0, 4.0))

    # Simular movimento de mouse antes de interagir
    page.mouse.move(random.randint(100, 800), random.randint(100, 600))
    time.sleep(random.uniform(0.5, 1.5))
    page.mouse.move(random.randint(200, 700), random.randint(150, 500))
    time.sleep(random.uniform(0.3, 0.8))

    # Interagir com a página
    page.fill("input[name='origin']", "JFK")
    time.sleep(random.uniform(0.3, 0.7))
    page.fill("input[name='destination']", "LAX")
    time.sleep(random.uniform(0.5, 1.0))
    page.click("button[type='submit']")

    page.wait_for_timeout(5000)
    browser.close()

Passo 3: Pacing e simulação comportamental

O pacing é o que separa automação que passa do PerimeterX da que é bloqueada. Aqui está uma função utilitária para delays humanos:

import random
import time
import math

def human_delay(min_s=0.5, max_s=2.0):
    """Delay com distribuição não-uniforme, mais natural."""
    base = random.uniform(min_s, max_s)
    jitter = random.gauss(0, 0.15)
    return max(0.1, base + jitter)

def human_mouse_move(page, target_x, target_y, steps=None):
    """Move o mouse em trajetória bezier com micro-tremores."""
    if steps is None:
        steps = random.randint(15, 40)
    current = page.evaluate("[window.screenX + window.outerWidth/2, window.screenY + window.outerHeight/2]")
    for i in range(steps):
        t = i / steps
        # Curva bezier quadrática simplificada
        mid_x = (current[0] + target_x) / 2 + random.uniform(-50, 50)
        mid_y = (current[1] + target_y) / 2 + random.uniform(-50, 50)
        x = (1-t)**2 * current[0] + 2*(1-t)*t * mid_x + t**2 * target_x
        y = (1-t)**2 * current[1] + 2*(1-t)*t * mid_y + t**2 * target_y
        # Adicionar tremor micro
        x += random.uniform(-2, 2)
        y += random.uniform(-2, 2)
        page.mouse.move(x, y)
        time.sleep(random.uniform(0.005, 0.02))

def human_type(page, selector, text):
    """Digita caractere por caractere com timing variável."""
    page.click(selector)
    time.sleep(human_delay(0.3, 0.8))
    for char in text:
        page.keyboard.type(char)
        time.sleep(random.uniform(0.05, 0.15))
    time.sleep(human_delay(0.2, 0.5))

# Uso: respeitar rate limits razoáveis (máx ~60 req/min por sessão)
MAX_REQUESTS_PER_MINUTE = 60
REQUEST_COUNT = 0

def rate_limited_goto(page, url):
    global REQUEST_COUNT
    if REQUEST_COUNT >= MAX_REQUESTS_PER_MINUTE:
        time.sleep(60)
        REQUEST_COUNT = 0
    page.goto(url, wait_until="domcontentloaded")
    REQUEST_COUNT += 1
    time.sleep(human_delay(1.0, 3.0))

Sites que usam PerimeterX

O PerimeterX é particularmente popular em setores com alto valor por transação e forte problema de bots:

• Companhias aéreas: United Airlines, American Airlines, Delta Air Lines. Bots tentam arbitrar tarifas, monitorar disponibilidade de award seats e fazer scalping de milhas.
• E-commerce de luxo: Neiman Marcus, Saks Fifth Avenue. Proteção contra scalping de produtos limitados e monitoramento de preços por concorrentes.
• Ticketing: Diversos sites de venda de ingressos usam PerimeterX para combater scalping de tickets.
• Financeiro: Algumas plataformas de trading e fintechs usam HUMAN para proteção contra account takeover.

Para identificar se um site usa PerimeterX, procure pelos cookies _px3 e _pxhd nas DevTools, ou pelo header x-px-captcha nas respostas HTTP. A presença do script px.js ou pxCaptcha no HTML também é indicativa.

Considerações éticas e legais

Automação contra PerimeterX deve ser sempre feita dentro de um framework ético e legal:

• Respeite os termos de serviço: Verifique os ToS do site alvo. Alguns sites permitem scraping de dados públicos; outros proíbem qualquer automação.
• Respeite o robots.txt: O robots.txt indica quais partes do site podem ser crawleadas. Sempre verifique antes de automatizar.
• Rate limiting responsável: Mantenha uma taxa de requisições que não degrade a experiência de outros usuários. 60 requisições por minuto por sessão é um limite razoável para a maioria dos sites.
• GDPR e CCPA: Se você coleta dados pessoais de usuários europeus ou californianos, esteja ciente das obrigações de privacidade. Consulte a documentação oficial do GDPR para detalhes.
• Pentest autorizado: Se você está fazendo security research, obtenha autorização por escrito do proprietário do site antes de testar.

Configuração ProxyHat para PerimeterX

Para máxima eficácia contra PerimeterX, recomendamos a seguinte configuração ProxyHat:

• Tipo de proxy: Residencial (residential IPs de ISPs reais têm a melhor reputação contra PerimeterX).
• Geo-targeting: Use country e city matching com o timezone do navegador. Se o browser está em America/New_York, use country-US-region-new_york-city-new_york_city.
• Sessão sticky: Use sid-XYZ para manter o mesmo IP durante toda a sessão do navegador. O PerimeterX constrói perfil comportamental por IP — trocar de IP a cada requisição é contraproducente.
• Concorrência: Limite a 1-2 sessões simultâneas por IP para evitar rate limiting.

Consulte nossa página de preços para planos residenciais, ou explore os locais disponíveis para geo-targeting detalhado. Para casos de uso específicos de scraping, veja nossa documentação de web scraping e SERP tracking.

Para detalhes técnicos completos de configuração, consulte a documentação oficial do ProxyHat.

Erros comuns e edge cases

1. Headless mode detectado

Mesmo com stealth plugins, o modo headless puro do Chromium é detectável via várias propriedades (ausência de Notification.permission, navigator.permissions inconsistente, dimensões de janela com valor 0). Sempre que possível, use headless=False com Xvfb em servidores Linux.

2. Inconsistência timezone vs. IP geolocation

Se seu proxy está em Los Angeles mas o browser reporta timezone="Europe/London", o PerimeterX flagga imediatamente. Sempre sincronize timezone do contexto com a geolocalização do proxy.

3. Reuso de cookies _px3 entre sessões

Tentar reusar um _px3 válido de uma sessão anterior em uma nova sessão com IP diferente geralmente resulta em bloqueio. O token é vinculado ao contexto de fingerprinting. Deixe o browser gerar um novo _px3 naturalmente.

4. Ausência de sinais comportamentais

Navegar para uma página e imediatamente clicar em um botão sem nenhum evento de mouse é a flag comportamental mais óbvia. Sempre injete pelo menos 3-5 eventos de mousemove antes de qualquer clique.

5. TLS fingerprint incompatível

Se você usa requests ou aiohttp diretamente (sem browser), o JA3 será o da biblioteca Python, não do Chrome. O PerimeterX bloqueia JA3 de bibliotecas HTTP conhecidas. Use sempre um browser real (Playwright/Puppeteer) para passar pelo challenge JS.