Protezione anti-scraping: come funzionano i moderni sistemi anti-bot

Il web scraping è la raccolta automatizzata di dati dai siti web: prezzi dei concorrenti, contenuti, contatti, annunci, disponibilità di magazzino. Di per sé è legale quando riguarda dati accessibili pubblicamente, ma diventa un problema quando sovraccarica l’infrastruttura, ruba contenuti originali, alimenta il dumping o serve a preparare frodi (attacchi di forza bruta sugli account, incetta di prodotti scarsi). Secondo varie stime, il traffico automatizzato costituisce oggi circa la metà di tutto il traffico internet, e la protezione dallo scraping indesiderato è diventata un’industria a sé.

L’idea chiave su cui si regge tutta la protezione moderna: distinguere un programma da una persona, e un client automatizzato da un altro, è possibile ancora prima che il server consegni anche un solo byte di contenuto. La decisione di blocco viene presa spesso nei primi millisecondi della connessione. Qui sotto vediamo che cosa viene monitorato esattamente, con quali metodi ci si difende, a che cosa prestare attenzione, come gli scraper aggirano le restrizioni e quali soluzioni pronte esistono.

Quali parametri vengono monitorati

I sistemi moderni non si affidano a un solo indizio. Raccolgono decine di segnali a diversi livelli dello stack di rete e li condensano in un unico «punteggio di fiducia» (trust score / bot score). Più basso è il punteggio, più alta è la probabilità di ricevere un captcha, un rallentamento o un blocco. In linea di massima i segnali si dividono in vari strati.

1. Livello di rete e IP

Lo strato più basilare. Si analizzano la reputazione dell’indirizzo IP, la sua appartenenza (ASN), il tipo di rete. Le richieste dai data center di AWS, GCP e Azure saltano all’occhio all’istante — gli utenti normali non navigano così. Si tengono d’occhio la frequenza e il ritmo delle richieste da uno stesso indirizzo (rate limiting), i picchi improvvisi, gli accessi a URL atipici. I sistemi migliori mantengono database propri di IP «sporchi», sorpresi a commettere abusi in tutta la loro rete.

2. Fingerprint TLS (JA3 / JA4 / JA4+)

Uno dei segnali più affidabili e più difficili da falsificare, perché lavora a livello di rete — prima che venga eseguito qualsiasi JavaScript. Quando stabilisce la connessione HTTPS, il client invia un messaggio ClientHello in cui elenca le cifrature supportate, le estensioni, le curve ellittiche, le versioni di protocollo e i valori ALPN — in un ordine rigorosamente definito. Questo insieme viene ridotto, tramite hash, a un breve fingerprint:

• JA3 (2017) — il metodo classico, un hash MD5 dei campi del ClientHello. Il problema: TLS 1.3 ha introdotto i valori casuali GREASE, per cui l’hash «fluttua» da una richiesta all’altra.
• JA4 / JA4+ (FoxIO, 2023) — il sostituto moderno: ordina le estensioni alfabeticamente ed elimina GREASE, così il fingerprint resta stabile anche con l’ordine randomizzato. JA4+ è una famiglia di fingerprint (compresi la risposta del server JA4S, HTTP/2 e altri).

La forza principale del metodo è la verifica di coerenza: se lo User-Agent sostiene di essere Chrome 120 ma il fingerprint TLS corrisponde alla libreria Python requests o a curl, il client viene bloccato immediatamente. A questo si aggiungono i fingerprint di HTTP/2 (ordine e valori dei frame SETTINGS, prioritizzazione) e dei parametri di trasporto di HTTP/3 (QUIC). Il trend più recente è tenere conto delle firme post-quantum e delle nuove estensioni TLS che compaiono nelle build attuali di Chromium.

3. Intestazioni HTTP

Si controllano non solo i valori in sé, ma anche la loro composizione, l’ordine e la coerenza reciproca:

• lo User-Agent e la sua corrispondenza con il comportamento reale del client;
• la presenza e la correttezza di Accept, Accept-Language, Accept-Encoding, Referer;
• i moderni Client Hints (Sec-CH-UA, piattaforma, condizione mobile);
• l’ordine delle intestazioni — ogni browser ha il suo, caratteristico e stabile.

Una lingua dell’intestazione Accept-Language che non corrisponde al paese dell’IP di uscita è un motivo frequente di sospetto.

4. Fingerprint del browser

Se il client esegue JavaScript, il sito compone un’«impronta del dispositivo» a partire da centinaia di caratteristiche:

• Canvas fingerprint — il risultato del rendering di un’immagine nascosta, unico per la combinazione GPU/driver/sistema operativo;
• WebGL / WebGPU — rivelano il modello della scheda video e la versione del driver;
• AudioContext — microdifferenze nell’elaborazione del segnale audio;
• l’elenco dei font installati, la risoluzione e i parametri dello schermo, il fuso orario, la lingua;
• le proprietà dell’oggetto navigator, i plugin, le API disponibili.

E di nuovo l’essenziale è la coerenza. Se il Canvas viene renderizzato come da una potente GPU dedicata, ma WebGL dichiara una grafica integrata Intel — è una configurazione «impossibile», flag immediato. I sistemi controllano anche che il fingerprint non cambi troppo spesso (indizio di randomizzazione) e che non sia troppo statico tra le sessioni (indizio di falsificazione).

5. Indizi di automazione

Marcatori diretti dei browser headless e degli strumenti di automazione: il flag navigator.webdriver, tracce del protocollo CDP (Chrome DevTools Protocol), plugin e API mancanti, rendering software (SwiftShader) al posto di una GPU hardware, dimensioni della finestra non standard. Anche una generazione troppo rapida del fingerprint Canvas (più veloce di quanto farebbe in tempo un browser reale) è un segnale.

6. Biometria comportamentale

Lo strato più «umano», che sempre più spesso decide l’esito. I modelli di machine learning analizzano come il visitatore interagisce con la pagina: le traiettorie del mouse, il ritmo e la velocità dello scroll, le pause, la cadenza dei clic e della digitazione, la sequenza di navigazione. Una persona vera muove il cursore in modo caotico, scorre in modo irregolare, ogni tanto manca il bersaglio. Un bot si muove in linea retta, scorre a velocità costante e non sbaglia mai. L’assenza totale di movimenti del mouse durante la navigazione è sospetta già di per sé.

Quali metodi di protezione esistono

La protezione si costruisce come una torta a strati: ogni livello filtra una parte del traffico indesiderato e, tutti insieme, alzano il costo dell’attacco. Gli approcci principali:

Rate limiting e throttling. Limitare il numero di richieste per IP/sessione nell’unità di tempo e rallentare al superamento delle soglie. Uno strato di base semplice ma imprescindibile.

robots.txt. Un file dichiarativo che indica quali sezioni possono essere esplorate e da quali bot. Funziona solo con i crawler «onesti»: un bot in buona fede lo rispetta, uno malintenzionato lo ignora. È uno strumento di accordo, non di coercizione. Secondo i dati di Cloudflare, solo circa un terzo dei domini principali ha un robots.txt.

WAF e liste di reputazione. Il web application firewall blocca i pattern malevoli noti e il traffico proveniente da IP/ASN con cattiva reputazione.

CAPTCHA e scoring invisibile. L’evoluzione è passata dal testo distorto e dalla selezione di immagini («semafori», «strisce pedonali») ai sistemi invisibili che valutano in silenzio il comportamento in background (reCAPTCHA v3, Cloudflare Turnstile, hCaptcha). Il challenge visibile, ormai, è la conseguenza di un punteggio di fiducia basso, non la prima linea di difesa.

Proof-of-work (prova di lavoro). Il browser risolve, senza farsi notare, un problema crittografico. Per un utente reale è gratis, ma per l’automazione di massa crea un costo computazionale asimmetrico che rende l’attacco economicamente svantaggioso. Questo approccio è alla base di Kasada e Friendly Captcha.

Challenge JavaScript. Il server consegna uno script che deve essere eseguito in un ambiente browser completo; i client HTTP senza motore JS vengono scartati.

Fingerprinting + scoring con ML. La raccolta di tutti i segnali visti sopra e la loro valutazione con modelli di machine learning in tempo reale. I sistemi più avanzati mantengono migliaia di modelli addestrati su siti specifici.

Honeypot e trappole. Link e campi invisibili per una persona, a cui reagiscono solo i bot. L’evoluzione dell’idea sono i «labirinti» e i tarpit: pagine esca generate all’infinito in cui i trasgressori si impantanano sprecando risorse (i link sono marcati nofollow per non danneggiare la SEO).

Offuscamento dinamico e polimorfismo. Cambiare di continuo il markup, i nomi delle classi, la struttura delle risposte e il codice stesso della protezione, perché gli scraper non possano essere «cuciti» su un template preciso e gli attaccanti non possano fare reverse engineering della protezione una volta per tutte.

Deployment sull’edge o lato applicazione. La protezione sull’edge (sulla CDN) intercetta i bot prima, a monte del server di origine, riducendo il carico. La protezione a livello di applicazione vede più contesto di business e può applicare la logica di scenari specifici. Le grandi aziende usano spesso entrambi gli strati.

Verifica dei bot «buoni» e agent trust. Meccanismi che permettono ai crawler legittimi (motori di ricerca, monitoraggio) di autenticarsi per non essere bloccati. Una direzione recente sono gli standard con cui gli agenti AI possono dichiarare chi sono e quali intenzioni hanno (addestramento, inferenza, ricerca), e il proprietario del sito può decidere chi lasciar passare.

A che cosa prestare attenzione quando costruisci la protezione

Alcuni principi pratici che distinguono una protezione che funziona da una di facciata:

Difesa a più strati. Un solo segnale non è affidabile. Un IP residenziale non salva nessuno se il fingerprint TLS grida «Python» e navigator.webdriver tradisce l’automazione. La forza sta nella verifica incrociata della coerenza di molti strati contemporaneamente.

Equilibrio con i falsi positivi (false positive). Una protezione troppo aggressiva colpisce gli utenti reali: le persone dietro un NAT aziendale, con una VPN, in modalità privata o con un browser poco comune possono sembrare sospette. Un acquirente bloccato è una conversione persa e più ticket al supporto. La qualità di una soluzione si misura in buona parte proprio da un FPR basso (False Positive Rate — la quota di falsi positivi, cioè la percentuale di utenti reali scambiati per bot per errore).

Non bloccare i bot utili. Googlebot, Bingbot, il monitoraggio e i bot di anteprima dei social devono passare. Per questo servono liste di autorizzati e verifica. Bloccare del tutto i crawler AI, per inciso, rende il sito invisibile alla ricerca basata su AI (ChatGPT, Perplexity ecc.): è una decisione di business, non solo tecnica.

Protezione separata per API ed endpoint mobili. Spesso i dati non vengono estratti dalle pagine, ma direttamente dalle API, dove il fingerprint del browser non esiste. Per le app mobili si usano l’attestation del dispositivo e gli SDK mobili.

Dare priorità a ciò che vale di più. Conviene concentrare la protezione rafforzata sui punti più preziosi e più attaccati — listini, ricerca, pagine prodotto, login, checkout — invece di spalmare controlli pesanti su tutto il sito.

Monitoraggio e aggiornamento. È una corsa agli armamenti. I vendor anti-bot aggiornano il rilevamento ogni settimana; una protezione configurata «una volta sola» invecchia. Servono dashboard di analisi del traffico bot e una revisione periodica delle regole.

Come gli scraper aggirano le restrizioni

Capire il lato dell’attacco è utile: mostra contro che cosa, esattamente, si costruisce la protezione. Lo scraping professionale oggi non è «cambiare lo User-Agent», ma un’imitazione coerente di un client reale su tutti gli strati contemporaneamente.

Rotazione dei proxy. Gli IP dei data center sono economici, ma si fanno scoprire facilmente. I proxy residenziali instradano il traffico attraverso reti domestiche reali e sembrano utenti normali; i proxy mobili sono ancora più affidabili, ma più cari. Gli IP vengono ruotati tra le richieste, scegliendo la geolocalizzazione in base al pubblico target del sito. Ma il cambio di IP da solo non serve a niente: non ripara né il fingerprint TLS né quello del browser.

Impersonazione TLS. Librerie come curl-impersonate e curl_cffi riproducono lo stack TLS di un browser vero, perché JA3/JA4 coincida con lo User-Agent dichiarato. Il principio chiave degli attaccanti: non cercare di sembrare «migliori» di un browser, ma essere il più possibile coerenti con esso — qualsiasi incongruenza tra gli strati è più pericolosa di un fingerprint «nella media».

Browser headless rinforzati (fortified). Selenium e Puppeteer allo stato puro (vedi la guida a Selenium) si tradiscono con i flag di automazione. Per questo si usano: - nodriver e undetected-chromedriver — eliminano le tracce di WebDriver e non usano il protocollo classico; - SeleniumBase nelle modalità UC/CDP; - Camoufox — un browser anti-detect basato su Firefox con iniezione del fingerprint a livello C++; - i plugin stealth per Puppeteer/Playwright (che però restano indietro rispetto agli aggiornamenti del rilevamento e col tempo «scadono»).

Un’analisi dettagliata e un confronto di questi strumenti si trovano nella panoramica 11 Best Anti-Bot Bypass Tools for Web Scraping.

Browser anti-detect. Multilogin, GoLogin, NestBrowser, AdsPower e simili creano profili isolati con fingerprint unici ma coerenti (Canvas, WebGL, font) — nati per la gestione di più account, ma molto usati anche nello scraping.

Imitazione del comportamento. Ritardi casuali, traiettorie del mouse «umane», scroll irregolare, pause, navigazione di riscaldamento prima dell’azione target — per superare l’analisi comportamentale.

Risoluzione dei captcha. Servizi come 2Captcha, Anti-Captcha o CapSolver restituiscono un token per reCAPTCHA, hCaptcha o Turnstile (nell’ordine di 1–2 $ ogni 1.000 risoluzioni). Ma costa tempo e denaro, quindi i professionisti puntano sulla prevenzione: non lasciare che il punteggio di fiducia scenda fino al punto in cui il captcha compare.

Servizi gestiti. Le scraping API chiavi in mano (Scrapfly, Bright Data Web Unlocker, ScraperAPI, Scrapeless) si prendono in carico tutta la complessità: un unico stack Chrome patchato, la rotazione di proxy residenziali, l’allineamento di TLS/HTTP/2/Canvas alle build reali del browser, la risoluzione dei challenge. Per l’attaccante significa trasferire al fornitore l’onere di sostenere la «corsa agli armamenti».

La conclusione principale è la stessa per entrambe le parti: non vince chi si maschera in modo più aggressivo, ma chi ha tutti gli strati coerenti tra loro. È proprio sulla ricerca delle incongruenze che si fonda il rilevamento.

Quali soluzioni esistono

Il mercato del bot management è maturo e affollato. Qui sotto i player chiave. I prezzi sono quasi sempre personalizzati (enterprise), quindi le cifre esatte vanno chieste ai vendor; i riferimenti riportati provengono da dati pubblici e hanno valore puramente orientativo.

Cloudflare Bot Management. Parte della più grande piattaforma CDN/di sicurezza al mondo, che serve circa il 20% del web. Usa machine learning e analisi comportamentale addestrati sui dati di decine di milioni di siti, il che le dà un’enorme visibilità di rete. Nell’ecosistema rientrano Turnstile (captcha invisibile), Bot Analytics e le più recenti linee AI: il blocco dei crawler AI (da luglio 2025 attivo di default per i nuovi domini, il «Content Independence Day»), la gestione tramite AI Crawl Control, il controllo del rispetto di robots.txt, un «labirinto» per i trasgressori e il marketplace Pay Per Crawl, dove gli editori possono far pagare alle aziende AI la scansione (risposta 402 Payment Required). La gestione bot di base è disponibile dai piani a pagamento; le funzionalità complete su Business/Enterprise. Dà il meglio come parte della piattaforma complessiva di Cloudflare.

DataDome. Uno dei leader del mercato, orientato a e-commerce, marketplace, travel, fintech e media. Punta sul machine learning in tempo reale: secondo dati pubblici mantiene decine di migliaia di modelli per singoli clienti. I punti di forza: la protezione di API e app mobili (attestation del dispositivo, SDK mobili), una bassa percentuale di falsi positivi grazie alla combinazione di segnali comportamentali e contestuali, modalità di reazione flessibili, dai challenge «morbidi» al blocco netto. Gli utenti lo valutano costantemente bene per la facilità di implementazione. In base ai riferimenti pubblici, i budget partono da circa 2.000–4.000 $ al mese per un traffico moderato e salgono a 12.000–25.000 $ al mese e oltre per grandi progetti multiregionali.

HUMAN (ex PerimeterX, confluita in HUMAN Security). Forte nell’analisi comportamentale e nell’ecosistema anti-frode: protezione dall’incetta di prodotti scarsi (bot scalper), dal credential stuffing, dal furto di account. Una buona scelta quando serve unire anti-bot e anti-frode con una reportistica avanzata e un’analisi matura.

Akamai Bot Manager. Il peso massimo enterprise per traffico grande e ad alto carico. Lavora sull’edge tramite Akamai Intelligent Edge, usa analisi comportamentale, machine learning e threat intelligence globale, offre policy granulari (block / challenge / ritardo / consegna di contenuti alternativi) e la separazione tra bot «buoni» e «cattivi». Ha il massimo senso per chi è già sullo stack Akamai.

Imperva Advanced Bot Protection. Una soluzione matura con una forte protezione delle API e una buona analitica; spesso viene valutata insieme al WAF di Imperva come protezione enterprise completa delle applicazioni.

Kasada. Punta sui challenge crittografici proof-of-work e sull’offuscamento dinamico: l’obiettivo è far schizzare in alto il costo dell’attacco per bot headless ed emulatori, senza captcha visibili (attrito minimo per le persone). Particolarmente efficace contro i bot che hanno già imparato a eludere il rilevamento imitando il comportamento, e contro emulazione/automazione. Adatto ai team a cui interessa la resistenza al retooling da parte degli attaccanti.

Arkose Labs. Combina il risk scoring con challenge interattivi e con l’approccio «rendere l’attacco economicamente svantaggioso»; forte negli scenari di protezione dalle frodi e dalla registrazione massiva di account falsi.

Netacea. Approccio agentless: si installa lato server/edge senza JS client né SDK, quindi è invisibile per gli attaccanti. Usa l’analisi dell’intento (valuta l’intenzione, non le firme) e l’integrazione con SIEM/SOAR.

Fastly Bot Management. Protezione sull’edge da ATO, scraping, DDoS a livello applicativo, credential stuffing e abuso della logica di business: una scelta logica per chi è già su Fastly.

I provider di CAPTCHA come strato a parte. Google reCAPTCHA (v2 — checkbox con fallback sulle immagini; v3 — scoring invisibile senza interazione), hCaptcha (non legato all’ecosistema Google), Cloudflare Turnstile (verifiche in background senza challenge visibile nella maggior parte dei casi), Friendly Captcha (proof-of-work). Si integrano sia da soli sia all’interno di piattaforme di bot management più grandi.

A grandi linee il mercato si può leggere così: Cloudflare, Akamai e Fastly sono forti sull’edge e nel consolidare la sicurezza web in un unico stack; DataDome e HUMAN vanno più in profondità a livello di applicazione, API e mobile; Kasada e Arkose puntano a rincarare l’attacco in modo asimmetrico; Imperva e Netacea offrono una protezione enterprise matura di applicazioni e API.

Dove sta andando il mercato

La protezione anti-scraping è una corsa agli armamenti senza fine, in cui le due parti evolvono in sincrono. Alcuni trend evidenti:

• Spostamento dalle firme al comportamento e al machine learning. Il rilevamento si appoggia sempre meno a regole statiche e sempre più alla biometria comportamentale e a modelli addestrati sul singolo sito.
• I segnali di rete come fondamenta. I fingerprint TLS/HTTP-2/HTTP-3 sono difficili da falsificare e agiscono prima del JS, quindi restano lo strato di base e il più affidabile; compaiono segnali nuovi come il TLS post-quantum.
• Challenge «morbidi» e proof-of-work al posto dei captcha molesti — per non rovinare la UX alle persone vere.
• I crawler AI come nuova categoria. L’arrivo della monetizzazione (pay-per-crawl), degli standard di identificazione dei bot e del concetto di «agent trust»: la domanda si sposta da «persona o bot?» a «a quale bot, e per quale scopo, concediamo l’accesso?».
• Attestation dei dispositivi e radici di fiducia hardware — soprattutto negli scenari mobili.

La protezione perfetta non esiste: uno scraper abbastanza motivato e finanziato, con proxy residenziali, uno stack browser patchato e risolutori di captcha, supererà quasi ogni barriera. L’obiettivo realistico della protezione non è rendere lo scraping impossibile, ma renderlo così costoso, lento e fragile da non ripagarsi più, senza colpire nel frattempo gli utenti reali e i bot utili.