Capire PerimeterX (HUMAN Security): rilevamento, segnali e bypass legittimo

Capire PerimeterX (HUMAN) è essenziale per chiunque costruisca pipeline di scraping o automazione su siti ad alta protezione. PerimeterX — ora HUMAN Security dopo l'acquisizione del 2020 — è uno dei sistemi anti-bot più diffusi su siti di e-commerce, airline e ticketing. A differenza di soluzioni più focalizzate su fingerprinting statico, PerimeterX pesa fortemente i segnali comportamentali: movimento del mouse, timing tra eventi, deviazione dalla media umana. Questo articolo spiega l'architettura del rilevamento PerimeterX, i cookie di challenge (_px3, _pxhd), i segnali di fingerprinting e TLS, e come configurare un setup legittimo con proxy residenziali ProxyHat e browser stealth.

Come funziona il rilevamento PerimeterX (HUMAN)

PerimeterX opera come un middleware lato server che si inserisce tra il CDN e l'origine. Quando una richiesta arriva, il modulo PerimeterX (installato come plugin NGINX, Apache, o via CDN integration) valuta una serie di segnali e decide se servire il contenuto, lanciare una challenge JavaScript, o bloccare con HTTP 403. La decisione si basa su un modello di machine learning addestrato su traffico reale, che combina segnali lato client e lato server.

Il flusso tipico di una challenge è:

1. Prima richiesta: il server restituisce la pagina con uno script PerimeterX inline o referenziato (tipicamente ./px.js o https://client.perimeterx.net/...).
2. Il script raccoglie fingerprint del dispositivo, segnali comportamentali e genera un payload crittografato.
3. Il payload viene inviato a un endpoint PerimeterX (/px/captcha o /px/xhr) per validazione.
4. In caso di successo, il server rilascia i cookie _px3 e _pxhd che permettono richieste successive senza challenge.
5. In caso di fallimento, l'utente vede un CAPTCHA interattivo (reCAPTCHA o hCaptcha) o un blocco HTTP 403.

I cookie _px3 e _pxhd sono la chiave del sistema di sessione. _px3 è un cookie crittografato che codifica il punteggio di rischio, timestamp, e identificatori di sessione. _pxhd è un cookie di binding che associa la sessione browser a un identificatore lato server. Entrambi hanno tipicamente una TTL di 30 minuti con sliding expiration — ogni richiesta valida rinnova la scadenza.

Architettura dei segnali di rilevamento

PerimeterX combina quattro categorie principali di segnali:

Categoria	Segnali specifici	Peso relativo
Comportamentale	Mouse movement, scroll velocity, click timing, keypress cadence, idle patterns	Alto (40-50%)
Device fingerprint	Canvas hash, WebGL renderer, screen metrics, navigator properties, font enumeration	Medio (25-30%)
TLS / rete	JA3/JA4 fingerprint, HTTP/2 settings, IP reputation, ASN classification	Medio (15-20%)
Sessione / cookie	Coerenza _px3/_pxhd, rotation frequency, cookie age	Basso (5-10%)

Il peso comportamentale è ciò che distingue PerimeterX dalla concorrenza. Un browser headless con fingerprint perfetto ma zero movimento del mouse verrà comunque flaggato dopo 2-3 richieste nella maggior parte dei casi.

Segnali di fingerprinting: Canvas, WebGL, navigator

Il fingerprinting Canvas è uno dei segnali più potenti. PerimeterX renderizza una stringa di testo su un elemento <canvas> con font e colori specifici, poi calcola un hash del pixel buffer. Il risultato dipende da GPU, driver, sistema operativo e versione del browser. Due browser Chromium identici su OS diversi produrranno hash differenti. Un browser headless senza GPU produrrà un hash vuoto o costante — un segnale immediato.

WebGL fingerprinting funziona in modo analogo: PerimeterX legge WEBGL_debug_renderer_info per ottenere UNMASKED_VENDOR_WEBGL e UNMASKED_RENDERER_WEBGL. Un browser headless su un server senza GPU mostrerà SwiftShader o Google SwiftShader come renderer — un indicatore classico di ambiente non-user.

I segnali navigator critici includono:

• navigator.webdriver — se true, è un flag immediato (Playwright/Puppeteer default)
• navigator.plugins — browser reali hanno plugin (Chrome PDF, ecc.); headless spesso ha array vuoto
• navigator.languages — deve essere un array non vuoto coerente con Accept-Language
• navigator.platform — deve corrispondere a User-Agent e TLS fingerprint
• window.chrome — oggetto presente in Chrome reale, assente in headless

Per approfondire il fingerprinting del browser, la EFF Cover Your Tracks tool dimostra quanti segnali un browser rivela. La documentazione MDN sul Canvas API descrive le API che PerimeterX sfrutta per generare hash identificativi.

TLS fingerprinting: JA3 e JA4

Il fingerprint TLS è uno dei segnali di rete più importanti. JA3 è un metodo sviluppato da Salesforce che crea un hash delle ClientHello TLS — version, cipher suites, extensions, elliptic curves. Il risultato identifica univocamente la combinazione browser+OS+libreria TLS. PerimeterX mantiene un database di JA3 noti: se il tuo JA3 corrisponde a requests/urllib3 Python invece che a Chrome reale, sei flaggato immediatamente, indipendentemente dal User-Agent.

JA4 è l'evoluzione più recente che separa i componenti del fingerprint in campi ordinati, rendendo più facile classificare varianti. Un client Python requests con header Chrome ma JA3 Python viene rilevato in meno di 100ms dal primo handshake.

Per superare il fingerprint TLS, devi usare un browser reale (Chromium via Playwright) o una libreria che replica il JA3 di un browser target. Playwright avvia un Chromium vero, quindi il JA3 corrisponde a quello di Chrome — questo è un vantaggio significativo rispetto a requests + header spoofing.

Segnali comportamentali: il cuore di PerimeterX

Qui PerimeterX si differenzia maggiormente da DataDome e Akamai. Mentre DataDome pesa molto il fingerprinting statico e la reputazione IP, e Akamai Bot Manager si concentra su cookie challenge e JWT, PerimeterX costruisce un profilo comportamentale continuo:

• Mouse movement entropy: misura la deviazione dal percorso ottimo tra due punti. I bot tendono a muoversi in linee rette o curve perfette; gli umani hanno jitter e correzioni.
• Click timing: tempo tra page load e primo click, tempo tra click successivi. Distribuzione troppo uniforme = bot.
• Scroll velocity: scroll istantaneo o a velocità costante è sospetto. Gli umani scrollano a burst con decelerazione.
• Keypress cadence: nei form, il timing tra tasti. Bot con type() istantaneo è immediatamente rilevato.
• Idle time: tempo di inattività tra azioni. Sessioni con 0ms di idle tra ogni azione sono chiaramente automatizzate.

PerimeterX accumula questi segnali in una finestra di 30-60 secondi prima di decidere. Questo significa che anche se superi la challenge iniziale, un pattern comportamentale non-umano nelle richieste successive triggera un re-challenge o un blocco silenzioso (HTTP 403 con corpo vuoto).

Confronto: PerimeterX vs DataDome vs Akamai

Caratteristica	PerimeterX (HUMAN)	DataDome	Akamai Bot Manager
Focus principale	Comportamentale	Fingerprint + IP	Cookie challenge + JWT
Challenge JS	Sì (px.js)	Sì (datadome.js)	Sì (_abck cookie)
Peso comportamentale	Alto (40-50%)	Medio (20-30%)	Medio-basso (15-25%)
Fingerprint TLS	Sì (JA3/JA4)	Sì	Sì
CAPTCHA	reCAPTCHA / hCaptcha	Custom / hCaptcha	Raramente (silenzioso)
Siti tipici	Airline, e-com US	EU retail, media	Enterprise, banking

La differenza pratica: su PerimeterX, anche con IP residenziale perfetto e fingerprint pulito, senza movimento del mouse realistico riceverai un blocco entro poche richieste. Su DataDome, un fingerprint pulito + IP residenziale spesso basta. Su Akamai, la challenge iniziale è più complessa ma una volta superata, il monitoraggio comportamentale è meno aggressivo.

Configurazione pratica: Playwright stealth + proxy residenziali ProxyHat

Per un accesso legittimo a siti protetti da PerimeterX — ad esempio per ricerca di mercato autorizzata, monitoraggio prezzi nel rispetto dei ToS, o test di sicurezza con autorizzazione — serve un setup che replichi un browser reale su tutti i vettori di rilevamento. Ecco una configurazione concreta con Playwright, playwright-extra con plugin stealth, e proxy residenziali ProxyHat.

Setup base con proxy residenziale e sessione sticky

from playwright.sync_api import sync_playwright
import random, time

# ProxyHat residential proxy with US geo-targeting and sticky session
proxy_config = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US-session-sess1a2b3c",
    "password": "YOUR_PASSWORD"
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # headless=True viene rilevato più facilmente
        proxy=proxy_config,
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-sandbox",
            "--disable-dev-shm-usage"
        ]
    )
    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/124.0.0.0 Safari/537.36"
    )
    page = context.new_page()
    page.goto("https://www.example.com")
    time.sleep(random.uniform(2.5, 4.0))  # pacing umano
    page.close()
    browser.close()

La sessione sticky (session-sess1a2b3c) mantiene lo stesso IP per tutta la durata della sessione. Questo è critico: se l'IP cambia a metà sessione, PerimeterX invalida immediatamente i cookie _px3/_pxhd e re-challenge. Per rotazione tra sessioni diverse, cambia l'ID sessione.

Simulazione comportamentale: movimento del mouse realistico

import random, math

def human_mouse_move(page, start_x, start_y, end_x, end_y, steps=25):
    """Simula movimento del mouse con curve bezier e jitter."""
    # Punto di controllo per curva quadratic bezier
    ctrl_x = (start_x + end_x) / 2 + random.uniform(-80, 80)
    ctrl_y = (start_y + end_y) / 2 + random.uniform(-80, 80)
    
    for i in range(steps + 1):
        t = i / steps
        # Bezier quadratica
        x = (1-t)**2 * start_x + 2*(1-t)*t * ctrl_x + t**2 * end_x
        y = (1-t)**2 * start_y + 2*(1-t)*t * ctrl_y + t**2 * end_y
        # Jitter umano
        x += random.uniform(-2, 2)
        y += random.uniform(-2, 2)
        page.mouse.move(x, y)
        time.sleep(random.uniform(0.008, 0.025))  # 8-25ms tra step

# Uso: muovi verso un elemento prima di cliccare
human_mouse_move(page, 100, 100, 450, 320, steps=30)
time.sleep(random.uniform(0.1, 0.3))  # pausa pre-click
page.mouse.click(450, 320)

Questa funzione genera un percorso curvilineo con jitter — il tipo di movimento che PerimeterX si aspetta da un utente reale. La pausa di 100-300ms prima del click è importante: click immediati dopo il movimento sono sospetti.

Pacing e rate limiting

import random, time

class PXAwarePacer:
    """Gestisce il ritmo delle richieste per evitare detection comportamentale."""
    
    def __init__(self, min_delay=3.0, max_delay=8.0, jitter=True):
        self.min_delay = min_delay
        self.max_delay = max_delay
        self.jitter = jitter
        self.request_count = 0
    
    def wait(self):
        base = random.uniform(self.min_delay, self.max_delay)
        if self.jitter:
            # Occasionali pause lunghe (20% probabilità)
            if random.random() < 0.2:
                base += random.uniform(5.0, 15.0)
        time.sleep(base)
        self.request_count += 1
        
        # Ogni 15-20 richieste, pausa estesa tipo "l'utente si è allontanato"
        if self.request_count % random.randint(15, 20) == 0:
            time.sleep(random.uniform(30.0, 90.0))

pacer = PXAwarePacer(min_delay=3.0, max_delay=7.0)
# Prima di ogni page.goto() o azione significativa:
pacer.wait()

Con un pacing di 3-7 secondi tra richieste e pause occasionali più lunghe, il pattern si avvicina a quello di navigazione umana reale. Su siti airline come United o American Airlines, un rate superiore a 1 richiesta ogni 2 secondi sustained triggerà quasi certamente un challenge PerimeterX.

Siti che usano PerimeterX: casi reali

PerimeterX è particolarmente diffuso in specifici verticali:

• Airline US: United Airlines, American Airlines, Delta Airlines — proteggono search e booking flow per prevenire scraping di tariffe e scalping di award seats.
• E-commerce US luxury: Neiman Marcus, Saks Fifth Avenue — proteggono inventory e pricing data.
• Ticketing: alcuni siti di ticketing secondari usano PerimeterX per prevenire bot purchasing.
• Media/publishing: alcuni publisher US usano PerimeterX per proteggere contenuti premium.

Per identificare se un sito usa PerimeterX, cerca questi indicatori:

• Cookie _px3, _pxhd nella response
• Script px.js o riferimenti a client.perimeterx.net
• Header di risposta x-px o px-captcha
• Pagina di blocco con riferimento a https://www.perimeterx.net/...

Errori comuni e edge case

1. Headless senza modificazioni

Playwright/Puppeteer in modalità headless default espone navigator.webdriver=true e manca di window.chrome. PerimeterX rileva questo in meno di 200ms. Soluzione: usa headless=False con Xvfb su Linux, oppure patcha le proprietà con playwright-extra + stealth plugin.

2. IP datacenter su sito PerimeterX

IP datacenter (AWS, GCP, Azure) hanno ASN classificati come hosting provider. PerimeterX assegna un punteggio di rischio elevato a questi ASN. Anche con fingerprint perfetto, un IP datacenter su United Airlines riceverà un challenge immediato. Usa proxy residenziali con geo-targeting US per siti airline americani. Verifica le locazioni disponibili per ProxyHat.

3. Rotazione IP a metà sessione

Se usi rotazione per-request su un sito PerimeterX, i cookie _px3 ottenuti con IP A non saranno validi con IP B. PerimeterX lega il cookie all'IP + fingerprint. Soluzione: usa sessioni sticky per tutta la durata di una sessione di navigazione, poi ruota per la sessione successiva.

4. Mancanza di header realistici

Browser reali inviano header come sec-ch-ua, sec-ch-ua-platform, sec-fetch-dest, sec-fetch-mode, sec-fetch-site. Playwright con un user agent Chrome li genera automaticamente, ma se li sovrascrivi parzialmente, l'inconsistenza viene rilevata.

5. Timeout troppo brevi

La challenge JS PerimeterX può richiedere 3-8 secondi per completarsi. Se il tuo script ha un timeout di 5 secondi sulla navigazione, potrebbe interrompere la challenge prima che rilasci i cookie. Imposta timeout di almeno 30 secondi per la prima navigazione.

Setup ProxyHat: configurazione completa

Per configurare ProxyHat per accesso a siti PerimeterX, ecco i parametri chiave:

Parametro	Valore consigliato	Motivo
Tipo proxy	Residenziale	ASN residenziale, non flaggato come datacenter
Geo-target	country-US per siti US	Coerenza con timezone e locale del browser
Sessione	Sticky (session-XYZ)	Mantiene IP per durata sessione, valida i cookie _px3
Rotazione	Per-sessione, non per-request	Evita invalidamento cookie
Concorrenza	Max 5-10 sessioni concorrenti per IP	Evita pattern di traffico sospetto

Consulta la documentazione ProxyHat per dettagli su parametri avanzati. Per i piani e prezzi dei proxy residenziali, visita la pagina prezzi ProxyHat. Per use case specifici di web scraping e SERP tracking, vedi web scraping e SERP tracking.

Considerazioni etiche e legali

L'accesso a siti protetti da PerimeterX deve avvenire nel rispetto dei termini di servizio del sito target e delle leggi applicabili (Computer Fraud and Abuse Act negli US, GDPR in EU, ecc.). Le tecniche descritte in questo articolo sono appropriate per:

• Ricerca di sicurezza autorizzata: pentesting con autorizzazione scritta del target.
• Monitoraggio di prezzi competitivi: dove i ToS del sito lo permettono o dove esiste un relationship commerciale.
• QA e testing: testare le proprie difese anti-bot.
• Ricerca accademica: con approvazione IRB e rispetto di robots.txt.

Queste tecniche non sono appropriate per scalping di ticket, credential stuffing, o scraping massivo in violazione di ToS. PerimeterX esiste per proteggere siti da abuso; aggirarlo per scopi legittimi richiede giudizio etico e conformità legale. Rispetta sempre robots.txt e i Terms of Service del sito target.

Key Takeaways

• PerimeterX pesa il comportamento più del fingerprint: anche con fingerprint perfetto, senza movimento del mouse realistico verrai bloccato entro poche richieste.
• I cookie _px3 e _pxhd sono legati all'IP: usa sessioni sticky, non rotazione per-request.
• IP datacenter = blocco immediato: usa proxy residenziali con geo-targeting coerente.
• JA3/JA4 TLS fingerprint identifica il client: usa un browser reale (Playwright Chromium), non requests con header spoofati.
• Pacing è critico: 3-7 secondi tra richieste con pause occasionali lunghe simula navigazione umana.
• Headless va patchato: usa headless=False + Xvfb o stealth plugin per nascondere navigator.webdriver.

FAQ

Cos'è PerimeterX (HUMAN Security)?

PerimeterX — ora HUMAN Security dopo l'acquisizione del 2020 — è una piattaforma anti-bot che protegge siti web da automazione malevola. Si differenzia dai competitor per il forte peso sui segnali comportamentali (movimento mouse, timing click, scroll velocity). Usa cookie challenge (_px3, _pxhd), fingerprinting dispositivo, TLS/JA3 e reputazione IP per classificare il traffico come umano o bot.

Perché PerimeterX importa per chi usa proxy?

PerimeterX rileva non solo il fingerprint del browser ma anche la coerenza tra IP, fingerprint e comportamento. Un proxy datacenter con fingerprint perfetto viene comunque bloccato per l'ASN. Un proxy residenziale con rotazione per-request invalida i cookie di sessione. Chi usa proxy per scraping o automazione legittima deve scegliere il tipo giusto (residenziale), la strategia di rotazione giusta (sticky session) e il geo-targeting coerente con il browser.

Quale tipo di proxy funziona meglio con PerimeterX?

I proxy residenziali sono la scelta migliore per PerimeterX. Offrono IP con ASN residenziale (ISP reale, non datacenter), che PerimeterX classifica come basso rischio. È essenziale usare sessioni sticky per mantenere i cookie _px3 validi per tutta la durata della sessione di navigazione. Il geo-targeting deve essere coerente con timezone e locale del browser: per siti US, usa country-US con timezone America/New_York.

Come evitare i blocchi di PerimeterX in modo legittimo?

Usa un browser reale (Playwright Chromium con stealth plugin), proxy residenziali con sessione sticky, geo-targeting coerente, e simula comportamento umano: movimento del mouse curvilineo con jitter, pause di 3-7 secondi tra azioni, click timing non-uniforme. Evita headless non-patchato, IP datacenter, rotazione per-request, e rate superiori a 1 richiesta ogni 2 secondi. Rispetta sempre i ToS del sito e usa queste tecniche solo per scopi autorizzati.

Quali siti usano PerimeterX?

PerimeterX è diffuso su airline US (United, American, Delta), e-commerce luxury US (Neiman Marcus, Saks Fifth Avenue), e alcuni siti di ticketing. Per verificare se un sito usa PerimeterX, controlla la presenza dei cookie _px3/_pxhd, script px.js, o header di risposta x-px nella risposta HTTP.