Social Rocket
Avevamo Cloudflare Bot Fight Mode attiva. Il traffico sospetto arrivava comunque fino al sito.
Secondo la nostra esperienza da gestori, anche le challenge del browser non erano affidabili. Lo stesso valeva per un approccio provato in precedenza, chiamato „precursor“. Alla fine, la svolta non è stata un'altra funzione bot generica, ma una regola costruita con precisione sui pattern di richiesta effettivamente osservati.
I nostri agenti IA hanno isolato due diversi pattern di scraping dal traffico e li hanno tradotti in una strategia di blocco Cloudflare mirata. Le regole combinano caratteristiche del browser, Fetch Metadata, reti di origine, referrer, pagine di ingresso e il contrassegno di Cloudflare per i crawler verificati. Le richieste corrispondenti vengono terminate direttamente all'edge con HTTP 403.
Non pubblichiamo volutamente le impronte complete. Una regola anti-scraping non è il posto giusto per un changelog pubblico destinato agli scraper.
Cosa ci ha insospettito
Il primo segnale non è arrivato da un singolo evento di sicurezza, ma dalla combinazione di più punti di misurazione.
Uno snapshot di Minilytics mostrava 544 sessioni dirette con zero conversioni outbound misurate. Tra due ore completate, le sessioni dirette sono salite da 24 a 163.
Allo stesso tempo, in una finestra di 30 minuti analizzata, Cloudflare registrava circa 17.700 richieste HTTP, di cui circa 15.400 raggiungevano l'origin. Un estratto di cinque minuti dell'origin conteneva 1.980 richieste da 1.238 indirizzi IP diversi.
È importante distinguere le grandezze: una richiesta HTTP non è una sessione. E „zero conversioni“ significa, nel nostro contesto, zero eventi outbound configurati attivati – non zero vendite o zero fatturato dimostrati.
Avevamo comunque abbastanza segnale per scomporre meglio il traffico.
Pattern 1: il browser dichiarava Chrome, ma i metadati della richiesta non corrispondevano
Il primo gruppo grande ruotava massicciamente su indirizzi IP e paesi. I client si presentavano come browser Chrome su Windows e alternavano diverse identità Chrome.
Nel campione analizzato, 1.628 richieste da 1.120 indirizzi IP in 100 paesi appartenevano a questo pattern. Gran parte di esse richiedeva inoltre i dati delle pagine Next.js.
Di per sé non è ancora una prova di bot. Le richieste RSC nascono anche durante la normale navigazione su pagine Next.js.
La contraddizione è emersa altrove: le richieste dichiaravano un'identità di browser moderna, ma mancava completamente un'intestazione di Fetch Metadata che per questa classe di richieste ci saremmo aspettati.
La nostra prima logica di blocco combina quindi più condizioni:
- richiesta verso un host Srocket
- GET
- identità Chrome su Windows corrispondente al pattern osservato
- intestazione Fetch Metadata assente
- nessun bot verificato da Cloudflare
- nessun percorso interno di Next.js o di API
L'elenco concreto delle versioni non viene pubblicato.
Questa è la differenza decisiva rispetto a una regola grossolana del tipo „blocca la versione Chrome X“: non una singola proprietà attiva il blocco, ma la contraddizione tra l'identità del browser dichiarata e il contesto effettivo della richiesta.
Cloudflare fornisce con `cf.client.bot` un campo che contrassegna i bot e i crawler noti come legittimi. Questi crawler verificati vengono esclusi dalla logica di blocco.
Pattern 2: stavolta la richiesta del browser sembrava plausibile
Poco dopo è emerso un secondo pattern.
Queste richieste avevano intestazioni simili a quelle di un browser e usavano anche un valore `Sec-Fetch-Site` normale. Quindi non rientravano nella prima impronta.
Qui il segnale stava nella combinazione di provenienza, profilo del browser e pagina di destinazione.
Abbiamo osservato ingressi HTML diretti provenienti da un pool rotante di reti di origine. Le richieste usavano solo pochi profili di browser esattamente ricorrenti, arrivavano senza referrer e colpivano in modo mirato un piccolo gruppo delle nostre pagine di confronto.
Reti di origine in rotazione come queste sono anche il motivo per cui gli indirizzi IP da soli sono una cattiva impronta. Chi vuole capire meglio il lato tecnico può consultare il nostro confronto dei proxy, che illustra le differenze tra i tipi di proxy più diffusi e i relativi fornitori.
La nostra seconda logica di blocco combina quindi:
- un pool di origine osservato
- uno dei profili di browser esattamente ricorrenti
- GET
- referrer vuoto
- un piccolo gruppo definito di pagine di ingresso interessate
- nessun bot verificato da Cloudflare
Importante: non blocchiamo in modo generico un intero ASN e non blocchiamo in modo generico i visitatori senza referrer. Solo la combinazione delle caratteristiche porta al blocco.
Anche le reti concrete, gli user agent e le combinazioni di pagine restano interne.
Perché `Sec-Fetch-Site: none` non è un segnale di bot
Il secondo pattern mostra bene perché le singole intestazioni possono essere criteri di blocco pericolosamente scadenti.
Secondo MDN, `Sec-Fetch-Site: none` è un comportamento del browser del tutto normale, per esempio quando qualcuno digita direttamente un URL nella barra degli indirizzi o apre un segnalibro.
Una richiesta con questo valore non è quindi automaticamente sospetta.
Proprio per questo bloccheremo questo gruppo solo quando pool di origine, profilo esatto del browser, referrer vuoto e pagina di ingresso interessata coincidono contemporaneamente.
È più stretto di una regola bot generica – ed è volutamente così.
L'IA non ha „riconosciuto un bot“ – ne ha costruiti due modelli di regola
La parte per noi più interessante non è stata che un modello guardasse il traffico e dicesse „bot“.
L'IA è diventata utile solo quando da molte richieste singole sono emersi due pattern tecnici distinguibili:
1. Contraddizione d'identità: profilo del browser e Fetch Metadata non coincidono. 2. Impronta della sorgente: provenienza, profilo del browser, ingresso diretto e pagina di destinazione compaiono ripetutamente insieme.
A partire da questi pattern, i nostri agenti IA hanno derivato una strategia Cloudflare che abbiamo poi verificato con richieste reali e normali accessi da browser.
Per noi questa è la forma di IA più interessante in produzione: non un chatbot che spiega la sicurezza, ma agenti che traducono telemetria reale in una regola edge controllata.
Abbiamo già descritto altrove perché il traffico bot può falsare attribuzione e retargeting. Allo stesso tempo, il dibattito attuale sugli obblighi di trasparenza per i crawler IA mostra quanto sia diventato difficile attribuire in modo pulito il traffico automatizzato.
Nessun ulteriore deployment: la regola risiede direttamente in Cloudflare
La soluzione finale gira come Cloudflare Custom Rule esistente con l'azione Block.
Per questo non abbiamo dovuto distribuire l'applicazione né consumare un ulteriore slot di regole. La regola esistente per scanner e flood è stata estesa con i due pattern aggiuntivi.
La logica può essere riassunta solo a livello di principio:
- Gli scanner già confermati restano bloccati.
- Il pattern 1 scatta solo se identità del browser e Fetch Metadata sono in contraddizione nel modo osservato, la richiesta è un GET, non viene riconosciuto alcun bot verificato e non sono coinvolti percorsi interni di framework o API.
- Il pattern 2 scatta solo con la combinazione di pool di origine osservato, profilo del browser esattamente ricorrente, ingresso diretto senza referrer e una delle pagine di ingresso interessate.
- Solo quando un ramo corrisponde integralmente segue l'azione Block.
Le reti concrete, le versioni dei browser, gli user agent e l'espressione Cloudflare in produzione non vengono pubblicati. Uno scraper non deve sapere di più sulla regola.
Cloudflare stesso raccomanda le Custom Rule quando occorre combinare più campi della richiesta. Un'azione di blocco terminante viene applicata già a livello delle Custom Rule e impedisce che le richieste corrispondenti passino ai meccanismi bot successivi.
Cosa è successo dopo l'attivazione
Non ci siamo limitati a verificare che Cloudflare accettasse la regola. Abbiamo controllato in modo mirato che colpisse davvero il pattern desiderato e che gli accessi normali continuassero a funzionare.
I test di controllo hanno dato questi risultati:
- richiesta di prova con la prima impronta: Cloudflare 403
- stessa famiglia di browser con caratteristiche di navigazione normali: 200
- pagina di confronto pubblica con accesso normale: 200
- evento reale del secondo pattern: Custom rules / Block
- corrispondenze di regola mostrate durante la verifica: circa 1.300
L'andamento sull'origin è stato particolarmente chiaro: per il primo pattern, le richieste corrispondenti sono scese da 626 in un minuto completo a zero nell'ultimo intervallo di 18 secondi dell'estratto analizzato.
In una verifica Minilytics successiva, per 156 secondi non si sono aggiunte nuove sessioni dirette senza conversione outbound.
Questo non dimostra che il traffico indesiderato sia sparito per sempre. Mostra però che la nuova regola ha effettivamente intercettato all'edge i pattern osservati.
Perché non sosteniamo che non possano esserci falsi positivi
Abbiamo testato la regola con accessi normali simili a quelli di un browser e l'abbiamo volutamente circoscritta in modo stretto.
Tuttavia affermare „sicuramente senza falsi allarmi“ sarebbe poco serio.
Un vero visitatore diretto potrebbe, in teoria, soddisfare contemporaneamente più caratteristiche del secondo pattern – per esempio provenire da una rete di origine interessata, usare uno dei profili di browser ricorrenti e atterrare su una delle pagine coinvolte.
Per questo non consideriamo la regola una soluzione anti-bot universale, ma un'impronta specifica dell'incidente con possibilità documentata di ritiro.
Lo stesso vale per il primo pattern. Se gli scraper cambiano la loro identità di richiesta, anche un'impronta può perdere efficacia.
Il vantaggio sta proprio nel non promettere una soluzione magica e permanente: possiamo osservare, riclassificare e adeguare miratamente la regola edge.
Cosa portiamo a casa da questo incidente
Bot Fight Mode non era inutile. Ma una difesa anti-bot generica non è bastata a fermare questi due flussi di traffico.
Solo la combinazione di telemetria propria, analisi dei pattern assistita dall'IA e una Custom Rule Cloudflare precisa ha fatto la differenza.
Le nostre impronte concrete non sono trasferibili ad altri siti. Il metodo invece sì:
Non inseguire gli indirizzi IP. Non bloccare isolatamente singole intestazioni. Combinare più caratteristiche indipendenti della richiesta, escludere i crawler verificati, testare gli accessi normali dal browser e misurare poi l'effetto.
È così che i nostri agenti IA hanno trasformato un problema di traffico in una regola edge verificabile – senza consegnare agli scraper una guida universale.