Approfondimento su Akamai Bot Manager v2: come rileva l'automazione nel 2026

Se stai sviluppando strumenti di automazione autorizzata o conducendo ricerche di sicurezza, capire come funziona Akamai Bot Manager v2 è essenziale. Questo approfondimento su Akamai Bot Manager v2 esamina ogni strato del sistema di rilevamento — dai cookie _abck ai payload sensor_data, dai fingerprint TLS JA4 ai segnali HTTP/2 — e mostra come l'automazione legittima può passare in modo pulito con i proxy residenziali corretti.

Avviso legale: Le tecniche descritte in questo articolo sono destinate esclusivamente a ricerche di sicurezza autorizzate, monitoraggio di propri asset, test di penetrazione con consenso scritto e automazione legittima in conformità con i Termini di Servizio. L'accesso non autorizzato a sistemi protetti può violare il Computer Fraud and Abuse Act (CFAA) negli Stati Uniti e il GDPR nell'Unione Europea. Consulta sempre un legale prima di implementare queste tecniche.

Il sistema di segnali di Akamai Bot Manager v2: approfondimento

Akamai Bot Manager v2 rappresenta un salto qualitativo rispetto alla prima generazione. Il sistema non si basa più su una singola decisione binaria (bot vs umano) presa al momento della richiesta HTTP. Costruisce invece un punteggio di fiducia continuo (trust score) che si aggiorna ad ogni interazione, combinando segnali lato client, segnali di protocollo e reputazione dell'IP. Per chi fa akamai bot manager bypass in un contesto legittimo, comprendere questa architettura a strati è il primo passo.

Lo stack di segnali si compone di tre livelli:

• Livello 1 — Telemetria client: il file sensor.js (spesso offuscato come bmak) raccoglie centinaia di segnali dal browser e li impacchetta nel payload sensor_data.
• Livello 2 — Protocollo e fingerprint: JA4 TLS, HTTP/2 SETTINGS frame, e il nuovo key share post-quantum X25519MLKEM768 vengono confrontati con il User-Agent dichiarato.
• Livello 3 — Reputazione IP: l'ASN, il tipo di rete (datacenter vs residenziale), la storia dell'IP e la coerenza geografica contribuiscono al punteggio.

Un mismatch in qualsiasi livello può invalidare gli altri due. È per questo che l'approccio "solo proxy" o "solo browser stealth" non funziona da solo: serve coerenza end-to-end.

Cookie _abck e ak_bmsc: il meccanismo di trust continuo

Il cookie _abck è il cuore del sistema di trust di Akamai. Viene impostato alla prima richiesta HTTP e contiene un token JWT-like firmato che incorpora il punteggio di fiducia corrente. Il ciclo di vita del cookie _abck segue un pattern preciso:

1. Prima richiesta: il server imposta _abck con un valore iniziale che contiene ~-1~ nel campo di stato, indicando "non ancora validato".
2. Caricamento di sensor.js: il browser esegue il JavaScript di telemetria, raccoglie i segnali e invia il payload sensor_data tramite una richiesta POST allo stesso endpoint.
3. Validazione: se i segnali sono coerenti, il server aggiorna _abck con un nuovo valore che sostituisce ~-1~ con un timestamp e un punteggio valido.
4. Trust continuo: ogni richiesta successiva include _abck e il server può richiedere ri-validazioni periodiche.

Il cookie ak_bmsc è complementare ma più breve: ha una durata tipica di circa 30 minuti e serve come identificatore di sessione per il bot management. Se _abck viene invalidato (per esempio per un mismatch nei segnali), il server può forzare una ri-validazione completa, richiedendo un nuovo payload sensor_data.

Perché il cookie _abck si invalida

Il token _abck incorpora un hash dei segnali raccolti. Se una richiesta successiva presenta segnali incongruenti — per esempio un User-Agent diverso, un fingerprint TLS cambiato, o un'assenza di eventi mouse/keyboard dopo una navigazione che dovrebbe generarli — il server invalida il cookie e forza una ri-sfida. Questo è il motivo per cui un semplice cambio di proxy senza mantenere la sessione browser completa spesso porta a blocchi improvvisi.

Il payload sensor_data: come Akamai assembla i segnali comportamentali

Il sensor_data è il payload più critico del sistema. Viene generato dal JavaScript sensor.js (noto anche come bmak) e inviato come parametro POST codificato. Il payload contiene una concatenazione di oltre 200 campi, organizzati in sezioni che coprono eventi comportamentali, proprietà ambientali e metriche temporali.

Eventi mouse, scroll e touch

Il sensor_data akamai raccoglie una sequenza temporale di eventi di interazione. Per il mouse registra coordinate (clientX, clientY, screenX, screenY), timestamp ad alta risoluzione tramite performance.now(), e tipo di evento (mousemove, mousedown, mouseup, click, dblclick). Per lo scroll registra posizione, direzione e velocità. Su dispositivi touch registra pressione, area di contatto e coordinate multi-touch.

La chiave è che Akamai non guarda solo la presenza di eventi, ma la loro distribuzione statistica. Un mouse umano produce curve bezier naturali con micro-tremori, accelerazione non uniforme e pause irregolari. Un bot che genera eventi con distribuzione gaussiana perfetta o intervalli costanti (es. un evento ogni 16ms) viene identificato istantaneamente.

Proprietà schermo e GPU

Il payload include screen.width, screen.height, screen.colorDepth, window.devicePixelRatio, e le proprietà WebGL come WEBGL_debug_renderer_info che espongono il vendor e il renderer della GPU. Questi valori devono essere coerenti con il User-Agent dichiarato: se il UA dice Chrome su Windows ma il renderer WebGL riporta "Apple GPU", il mismatch è immediato.

Timing e prestazioni

Akamai misura il tempo tra l'invio del JavaScript e la ricezione del payload. Un tempo troppo breve (sotto i 200ms) indica esecuzione headless senza rendering. Il tempo troppo lungo o troppo uniforme tra richieste successive è ugualmente sospetto. La precisione di performance.now() viene verificata: alcuni browser headless restituiscono valori arrotondati o costanti che non corrispondono ai browser reali.

Perché un singolo campo mismatch invalida _abck

Il payload sensor_data viene hashato lato server e confrontato con il valore atteso. Se anche un solo campo è incongruente — per esempio navigator.hardwareConcurrency dice 8 ma il fingerprint TLS suggerisce un ambiente differente, oppure navigator.platform non corrisponde al UA — l'intero _abck viene invalidato. Questo design "fail-closed" significa che l'approccio corretto non è patchare singoli segnali, ma garantire coerenza totale.

Segnali di protocollo 2026: X25519MLKEM768, JA4 e HTTP/2 SETTINGS

Nel 2026, il fingerprinting a livello di protocollo è diventato il primo filtro di Akamai Bot Manager v2. Prima ancora di eseguire sensor.js, il server ha già tre segnali critici dal handshake TLS e dal primo frame HTTP/2.

X25519MLKEM768: il key share post-quantum

A partire da Chrome 131, Google ha abilitato di default il key share post-quantum X25519MLKEM768 nel handshake TLS 1.3, come parte dell'iniziativa di TLS ibrido post-quantum. Questo significa che il ClientHello di Chrome 131+ include un'estensione key_share con il gruppo X25519MLKEM768 (codepoint 0x11ec), oltre ai gruppi X25519 e P-256 tradizionali.

Akamai verifica la presenza di questo key share nel JA4 fingerprint. Se il User-Agent dichiara Chrome 131+ ma il ClientHello non include X25519MLKEM768, il mismatch è immediato. Le librerie HTTP che non supportano questo key share (come molte implementazioni Python e Node.js) vengono identificate come non-browser prima ancora di ricevere la pagina HTML.

JA4 TLS fingerprinting

Il fingerprint JA4 è l'evoluzione del JA3 e codifica quattro componenti del ClientHello TLS:

• JA4_a: versione TLS + SNI presence + numero estensioni (es. t13d1516h2_)
• JA4_b: cipher suites ordinate (es. 8daaf61527f0v2)
• JA4_c: estensioni ordinate (es. 00j40000c0_9c_)
• JA4_d: signature algorithms (aggiunto in JA4+)

Akamai mantiene un database di fingerprint JA4 per ogni combinazione browser-sistema operativo-versione. Un JA4 che non corrisponde a nessun browser noto riceve un punteggio di bot elevato prima ancora che sensor.js venga caricato. Il RFC 8446 (TLS 1.3) definisce la struttura del ClientHello, ma l'ordine delle estensioni e dei cipher suite è lasciato all'implementazione, creando proprio i pattern distintivi che Akamai sfrutta.

HTTP/2 SETTINGS fingerprint

Il frame SETTINGS di HTTP/2 contiene parametri di connessione che variano tra implementazioni client. Chrome, Firefox, Safari e curl inviano valori diversi per HEADER_TABLE_SIZE, ENABLE_PUSH, INITIAL_WINDOW_SIZE, MAX_CONCURRENT_STREAMS e MAX_FRAME_SIZE. L'ordine stesso dei parametri nel frame è un segnale.

Akamai confronta il fingerprint HTTP/2 SETTINGS con il User-Agent dichiarato. Se il UA dice Chrome ma il SETTINGS frame ha i valori tipici di curl o di una libreria Go, il mismatch invalida la sessione. Il RFC 9113 (HTTP/2) non prescrive l'ordine dei parametri SETTINGS, rendendo questo fingerprint un segnale affidabile.

Segnale di protocollo	Cosa verifica Akamai	Esempio Chrome 131+	Rischio di mismatch
JA4 TLS fingerprint	Cipher suites, estensioni, ALPN	t13d1516h2_8daaf61527f0v2	Alto se si usa una libreria HTTP non-browser
X25519MLKEM768 key share	Presenza nel ClientHello	Codepoint 0x11ec	Critico — assente in librerie pre-2025
HTTP/2 SETTINGS	Valori e ordine parametri	HEADER_TABLE_SIZE=65536, ecc.	Alto per client non-browser
Ordine header HTTP	Sequenza header dopo TLS	Host, Connection, sec-ch-ua...	Medio — varia per versione browser

Perché i proxy residenziali sono obbligatori per Akamai

Akamai Bot Manager v2 assegna un peso significativo alla reputazione dell'IP. Gli ASN datacenter (come AWS, DigitalOcean, Hetzner, OVH) sono pre-classificati come bot con un punteggio di base che parte già negativo. Non importa quanto perfetto sia il tuo sensor_data o quanto coerente sia il tuo JA4: se l'IP è in un range datacenter noto, il trust score inizia da una posizione di svantaggio che spesso porta al blocco diretto o a una sfida CAPTCHA.

I proxy residenziali, invece, usano IP assegnati a ISP reali (Comcast, AT&T, Vodafone, Telecom Italia). Questi IP hanno una storia di traffico organico che costruisce reputazione nel tempo. Akamai non può pre-classificare milioni di IP residenziali come bot senza causare falsi positivi massivi per utenti umani reali.

La geo-coerenza è un altro fattore. Se il tuo IP è a Francoforte ma il tuo Accept-Language è ja-JP e il fuso orario del browser è UTC+9, Akamai rileva l'incongruenza. Con i proxy residenziali geo-targetizzati puoi allineare IP, lingua e fuso orario in modo naturale.

Tipo di proxy	Reputazione IP per Akamai	Trust score iniziale	Rischio di blocco	Coerenza geo
Datacenter	Pre-classificato come bot	Basso (negativo)	Altissimo	Limitata (poche location)
Residenziale	Reputazione organica ISP	Medio-alto	Basso con browser corretto	Alta (paese + città)
Mobile	Reputazione ISP mobile	Alto	Minimo	Limitata (per operatore)

I proxy mobili hanno la reputazione più alta perché il traffico mobile è intrinsecamente eterogeneo (NAT condiviso, IP che cambiano naturalmente), rendendo quasi impossibile per Akamai pre-classificare questi IP. Tuttavia, per l'automazione desktop, i proxy residenziali con geo-targeting preciso sono spesso la scelta migliore perché simulano un utente domestico reale.

Implementazione pratica con ProxyHat e browser stealth

Per passare Akamai Bot Manager v2 in modo pulito, serve un approccio a tre strati: browser reale con stealth context, proxy residenziale geo-coerente, e comportamento umano simulato. Ecco un'implementazione pratica con Playwright e ProxyHat.

Configurazione del proxy residenziale

ProxyHat espone il gateway gate.proxyhat.com sulla porta 8080 per HTTP e 1080 per SOCKS5. Le flag di geo-targeting e sessione vanno nel username:

# HTTP proxy con geo-targeting US e sessione sticky
curl -x http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080 \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" \
  -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
  -H "Accept-Language: en-US,en;q=0.9" \
  "https://example.com"

# SOCKS5 proxy con geo-targeting Germania, città Berlino
curl -x socks5://user-country-DE-city-berlin-session-xyz789:pass@gate.proxyhat.com:1080 \
  "https://example.com"

Sessione browser stealth con Playwright

import asyncio
from playwright.async_api import async_playwright

async def akamai_resilient_session():
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=False,  # headless viene rilevato da sensor.js
            proxy={
                "server": "http://gate.proxyhat.com:8080",
                "username": "user-country-US-session-r7k2m",
                "password": "your_password"
            },
            args=[
                "--disable-blink-features=AutomationControlled",
                "--disable-features=IsolateOrigins,site-per-process"
            ]
        )
        context = await browser.new_context(
            user_agent=(
                "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                "AppleWebKit/537.36 (KHTML, like Gecko) "
                "Chrome/131.0.0.0 Safari/537.36"
            ),
            viewport={"width": 1920, "height": 1080},
            locale="en-US",
            timezone_id="America/New_York",
            extra_http_headers={
                "Accept-Language": "en-US,en;q=0.9"
            }
        )

        # Patch navigator.webdriver prima del caricamento
        await context.add_init_script("""
            Object.defineProperty(navigator, 'webdriver', {
                get: () => undefined
            });
            Object.defineProperty(navigator, 'plugins', {
                get: () => [1, 2, 3, 4, 5]
            });
            Object.defineProperty(navigator, 'languages', {
                get: () => ['en-US', 'en']
            });
        """)

        page = await context.new_page()
        await page.goto("https://example.com", wait_until="networkidle")

        # Attendi validazione _abck
        await page.wait_for_timeout(3000)
        cookies = await context.cookies()
        abck = next((c for c in cookies if c["name"] == "_abck"), None)
        if abck and "~-1~" not in abck["value"]:
            print("_abck cookie validato con successo")
        else:
            print("_abck non validato — genera interazioni umane")
            # Simula movimento mouse naturale
            await page.mouse.move(100, 200)
            await page.mouse.move(350, 180, steps=15)
            await page.mouse.click(350, 180)
            await page.wait_for_timeout(2000)

        await browser.close()

asyncio.run(akamai_resilient_session())

Il punto chiave è che il browser deve essere Chromium reale (non headless, o con stealth patches appropriate) per generare un sensor_data valido. Il proxy residenziale di ProxyHat garantisce che l'IP non sia pre-classificato, mentre il browser reale produce il JA4, il SETTINGS HTTP/2 e i segnali comportamentali corretti. Consulta la documentazione ProxyHat per dettagli sulle flag di sessione avanzate.

Rotazione delle sessioni

Per scenari che richiedono multiple sessioni concorrenti, ProxyHat supporta sessioni sticky tramite la flag session-. Ogni identificatore di sessione mappa a un IP residenziale differente, permettendo fino a 100+ sessioni concorrenti con IP distinti:

# Sessione 1 — IP residenziale US
curl -x http://user-country-US-session-sess001:pass@gate.proxyhat.com:8080 https://example.com

# Sessione 2 — IP residenziale US differente
curl -x http://user-country-US-session-sess002:pass@gate.proxyhat.com:8080 https://example.com

# Sessione 3 — IP residenziale UK
curl -x http://user-country-GB-session-sess003:pass@gate.proxyhat.com:8080 https://example.com

Esplora le posizioni proxy disponibili per allineare la geo-targeting con il tuo caso d'uso. Per il monitoraggio SERP o lo scraping web a larga scala, consulta i nostri casi d'uso di web scraping e SERP tracking.

Errori comuni e casi limite

1. Usare librerie HTTP invece di un browser reale

L'errore più comune è usare requests in Python o axios in Node.js e aspettarsi di passare Akamai. Queste librerie producono JA4 e SETTINGS HTTP/2 completamente diversi da qualsiasi browser reale. Anche con il proxy perfetto, il mismatch TLS è immediato. Soluzione: usa Playwright, Puppeteer o un browser Chromium instrumentato.

2. Headless senza stealth patch

Il modalità headless di Chromium imposta navigator.webdriver = true e ha differenze nel rendering WebGL che sensor.js rileva. Soluzione: usa headless=False con un display virtuale (Xvfb) o applica stealth patches come playwright-stealth.

3. Mismatch tra timezone IP e browser

Se il proxy è negli Stati Uniti ma il browser ha timezone="Europe/Rome", Akamai rileva l'incongruenza tra il fuso orario derivato dall'IP e quello dichiarato dal browser. Soluzione: imposta timezone_id e locale coerenti con la geo-targeting del proxy.

4. Sessioni troppo lunghe senza ri-validazione

Akamai richiede ri-validazioni periodiche del _abck. Se mantieni una sessione per ore senza generare nuovi eventi comportamentali, il trust score decade. Soluzione: genera interazioni periodiche (scroll, mouse move) o ruota la sessione ogni 30-60 minuti.

5. Rotazione IP senza rotazione cookie

Cambiare IP proxy senza resettare il context del browser significa che il nuovo IP presenta un _abck validato per un IP precedente. Akamai rileva l'incongruenza IP-cookie. Soluzione: quando ruoti l'IP, crea un nuovo browser context con nuovi cookie.

6. Ignorare il rate limiting

Anche con tutto perfetto, troppe richieste dalla stessa sessione o dallo stesso IP triggerano il rate limiting di Akamai. Mantieni una velocità realistica: 1-3 richieste per secondo per sessione, con jitter casuale.

Punti chiave

• Coerenza end-to-end: Akamai Bot Manager v2 verifica la coerenza tra IP, TLS, HTTP/2, JavaScript e comportamento. Un singolo mismatch invalida l'intera sessione.
• Browser reale obbligatorio: nessuna libreria HTTP può riprodurre il JA4, il SETTINGS HTTP/2 e il sensor_data di un browser Chromium reale.
• X25519MLKEM768 è critico nel 2026: Chrome 131+ include questo key share post-quantum di default; la sua assenza è un segnale di non-browser.
• Proxy residenziali non negoziabili: gli ASN datacenter sono pre-classificati come bot; solo IP residenziali con reputazione organica permettono un trust score iniziale accettabile.
• Geo-coerenza: IP, lingua, fuso orario e Accept-Language devono essere allineati.
• Comportamento umano: eventi mouse/scroll con distribuzione naturale e timing realistico sono essenziali per validare _abck.
• Automazione legittima: queste tecniche sono appropriate per monitoraggio autorizzato, ricerca di sicurezza e test di penetrazione con consenso, mai per frode o accesso non autorizzato.

Per iniziare con proxy residenziali geo-targetizzati, consulta le tariffe di ProxyHat e configura la tua prima sessione con gate.proxyhat.com:8080.

Domande frequenti

Che cos'è Akamai Bot Manager v2 e come rileva l'automazione?

Akamai Bot Manager v2 è un sistema di rilevamento bot multi-strato che combina telemetria JavaScript (sensor.js/bmak), fingerprint di protocollo (JA4 TLS, HTTP/2 SETTINGS, X25519MLKEM768), reputazione IP e analisi comportamentale. Assegna un trust score continuo tramite il cookie _abck che si aggiorna ad ogni interazione. A differenza della v1, non prende decisioni binarie ma valuta la coerenza tra tutti i segnali.

Perché il cookie _abck viene invalidato durante lo scraping?

Il cookie _abck incorpora un hash dei segnali raccolti da sensor.js. Se una richiesta successiva presenta segnali incongruenti — un User-Agent diverso, un fingerprint TLS cambiato, o assenza di eventi mouse dopo navigazione che dovrebbe generarli — il server invalida il cookie e forza una ri-sfida. Anche un singolo campo mismatch nel payload sensor_data è sufficiente per invalidare l'intera sessione.

Quale tipo di proxy è più efficace per superare Akamai Bot Manager?

I proxy residenziali sono i più efficaci perché usano IP assegnati a ISP reali con reputazione organica. Gli ASN datacenter sono pre-classificati come bot da Akamai, partendo con un trust score negativo. I proxy mobili hanno reputazione ancora più alta ma sono meno flessibili per il geo-targeting. Per l'automazione desktop, i proxy residenziali con geo-targeting per paese e città offrono il miglior equilibrio tra trust score e controllo.

Come evitare i blocchi di Akamai Bot Manager v2 con automazione legittima?

Usa un browser Chromium reale (non librerie HTTP), proxy residenziali geo-coerenti, e genera eventi comportamentali naturali. Assicura coerenza tra IP, timezone, lingua e User-Agent. Mantieni rate realistiche (1-3 richieste/secondo) con jitter. Ruota le sessioni ogni 30-60 minuti creando nuovi browser context. Usa sempre ProxyHat con gate.proxyhat.com:8080 e flag di sessione sticky per IP stabili.

Quali segnali TLS e HTTP/2 verifica Akamai nel 2026?

Akamai verifica il fingerprint JA4 (cipher suites, estensioni, ALPN), la presenza del key share post-quantum X25519MLKEM768 (codepoint 0x11ec, default in Chrome 131+), e il fingerprint HTTP/2 SETTINGS (valori e ordine dei parametri come HEADER_TABLE_SIZE e INITIAL_WINDOW_SIZE). Tutti questi segnali devono corrispondere al User-Agent dichiarato; un mismatch identifica il client come non-browser.