Indice dei contenuti dell'articolo:
Per anni il concetto di browser headless è stato quasi sinonimo di Chrome, Chromium, Puppeteer, Playwright e Selenium. Se bisognava automatizzare un login, renderizzare una pagina JavaScript, estrarre dati da un sito moderno o simulare una sessione browser completa, la scelta era quasi obbligata: avviare un’istanza di Chromium in modalità headless e pilotarla tramite Chrome DevTools Protocol.
Questa impostazione ha funzionato molto bene, ma ha anche creato un punto debole evidente: quando tutti usano lo stesso stack, tutti diventano riconoscibili nello stesso modo. I WAF, i sistemi anti-bot e le tecnologie di fingerprinting moderne hanno imparato a distinguere il browser reale dal browser automatizzato analizzando ogni piccolo dettaglio: il TLS handshake, l’ordine degli header HTTP, il comportamento JavaScript, la presenza di proprietà come navigator.webdriver, le anomalie di Canvas, WebGL, AudioContext, timezone, fonts, screen size, eventi mouse e tastiera.
Con l’avvento delle AI agentiche, però, lo scenario è cambiato molto velocemente. Non serviva più soltanto automatizzare qualche pagina: serviva dare a migliaia di agenti AI la possibilità di navigare, leggere, cliccare, compilare form, estrarre dati e mantenere sessioni isolate. Ed è bastato poco perché qualcuno si chiedesse: perché continuare a trascinarsi dietro tutto Chrome quando posso riscrivere da zero un motore headless più leggero, più veloce e progettato specificamente per automazione e scraping?
È in questo contesto che nasce Obscura, progetto disponibile all’indirizzo https://github.com/h4ckf0r0day/obscura.git. Il progetto si presenta come un browser headless open source scritto in Rust, pensato per AI agent, web scraping e browser automation. Supporta JavaScript tramite V8, espone il Chrome DevTools Protocol ed è quindi compatibile con strumenti come Puppeteer e Playwright. In altre parole: l’obiettivo dichiarato è permettere a chi già usa workflow basati su Chrome headless di sostituire il motore sottostante con qualcosa di più leggero, più rapido e più orientato allo scraping.
Perché Obscura è un segnale importante per la sicurezza Web
Obscura non è semplicemente “un altro wrapper” attorno a Chromium. La parte interessante è proprio questa: non è Chromium. È un motore costruito in Rust, con parsing HTML, DOM, runtime JavaScript e stack di rete propri. Questo cambia completamente il problema per chi fa sicurezza applicativa, perché molte difese anti-bot sono state costruite assumendo che l’automazione moderna usi Chrome headless, librerie HTTP riconoscibili o combinazioni abbastanza prevedibili di browser, sistema operativo e fingerprint.
Quando arriva un progetto che prova a ricostruire la superficie del browser da zero, l’equilibrio cambia. Non parliamo più soltanto di “nascondere Puppeteer” o di patchare qualche proprietà JavaScript. Parliamo della possibilità di creare un ambiente browser artificiale dove ogni layer può essere controllato, simulato, alterato e reso coerente con un profilo desiderato.
Questo non significa che Obscura sia invisibile. Anzi, proprio perché non è un browser completo general purpose, può introdurre inconsistenze, lacune e segnali rilevabili. Tuttavia il punto strategico è un altro: la velocità con cui oggi una tecnologia del genere può nascere, crescere e migliorare è enormemente superiore rispetto al passato. Con l’aiuto delle AI, sviluppare, portare API, correggere incompatibilità, imitare comportamenti del browser e testare i risultati contro sistemi reali diventa un ciclo molto più rapido.
Questo rende fragile l’idea che un WAF possa basarsi per sempre su firme statiche, blacklist di user agent, challenge JavaScript generiche o fingerprint noti. La superficie d’attacco si muove. E si muove molto più velocemente di quanto molte soluzioni commerciali riescano ad ammettere.
Come funziona il fingerprinting di un browser
Quando un utente visita un sito, il server non vede soltanto un indirizzo IP e una richiesta HTTP. Vede un insieme di segnali che, combinati, formano una sorta di “impronta digitale” del client. Questo è il concetto alla base del browser fingerprinting.
Il primo livello è quello di rete. Prima ancora che venga scaricata una pagina, il browser negozia una connessione TLS. In questa fase invia informazioni su versioni TLS supportate, cipher suite, estensioni, ordine dei parametri, ALPN e altre caratteristiche. Da questi dati nascono tecniche come JA3 e JA4, che permettono di identificare il tipo di client in base al modo in cui inizia la connessione HTTPS. Un Chrome reale, una libreria Python, cURL, un client Go, un bot custom o un browser embedded tendono ad avere firme diverse.
Il secondo livello è HTTP. Qui contano gli header inviati, il loro ordine, la presenza o assenza di alcuni campi, la coerenza tra User-Agent, Accept-Language, Client Hints, encoding supportati, protocollo HTTP/2 o HTTP/3, priorità, cookie e modalità di gestione delle redirect. Molti bot riescono a cambiare lo User-Agent, ma tradiscono la loro natura perché tutto il resto non corrisponde davvero a quel browser.
Il terzo livello è JavaScript e DOM. Un WAF moderno può iniettare codice JavaScript nel browser e verificare decine o centinaia di proprietà: navigator.webdriver, navigator.plugins, navigator.languages, screen.width, timezone, hardware concurrency, device memory, permissions API, WebGL vendor, renderer, Canvas fingerprint, AudioContext, font disponibili, comportamento degli eventi, tempi di esecuzione e compatibilità con API native. Il test non guarda soltanto il valore singolo: guarda soprattutto la coerenza complessiva.
Il quarto livello è comportamentale. Un umano muove il mouse in modo imperfetto, digita con tempi variabili, scrolla in modo irregolare, si ferma, torna indietro, sbaglia. Un agente o uno scraper tende invece a produrre pattern troppo puliti, troppo rapidi o troppo ripetitivi. Per questo i sistemi più evoluti non si limitano più a chiedersi “è Chrome?”, ma cercano di capire se dietro Chrome c’è davvero un essere umano.
Il problema per i WAF: Obscura simula quasi tutta la superficie osservabile
Obscura è interessante perché nasce già con una mentalità diversa rispetto ai browser headless tradizionali. Non vuole solo eseguire JavaScript. Vuole essere leggero, compatibile, automatizzabile e stealth. La documentazione del progetto parla di fingerprint randomization per GPU, screen, canvas, audio e battery, di valori realistici per navigator.userAgentData, di masking delle funzioni native, di navigator.webdriver impostato in modo da non esporre l’automazione, e di compatibilità CDP per pilotarlo con Puppeteer e Playwright.
Questo significa che molti controlli classici dei WAF vengono messi sotto pressione. Se un sistema anti-bot verifica il valore di navigator.webdriver, Obscura può nasconderlo. Se controlla Canvas o AudioContext, Obscura può generare un valore plausibile. Se controlla WebGL, può restituire vendor e renderer coerenti con un profilo Chrome. Se guarda User-Agent e Client Hints, può produrre valori compatibili. Se si aspetta un comportamento “simile Chrome” al livello CDP, l’obiettivo del progetto è proprio quello di esporsi come alternativa compatibile.
Ancora più delicato è il tema di JA3 e JA4. Storicamente, molti scraper venivano individuati perché usavano stack TLS non browser-like: librerie HTTP standard, handshake troppo diversi, cipher suite in ordine anomalo, HTTP/2 settings non coerenti. Ma quando un progetto punta esplicitamente a rendere coerente anche la parte TLS/HTTP con un profilo browser moderno, il margine difensivo si riduce.
Il risultato è chiaro: non sarà più realistico filtrare i bot in modo efficace affidandosi solo a fingerprint statici o a segnali standardizzati. Il WAF dovrà diventare più intelligente, più specifico, più contestuale. Dovrà osservare il traffico nel tempo, correlare segnali applicativi, distinguere gli utenti legittimi dagli agenti automatici e soprattutto aggiornare continuamente i propri test.
Security by obscurity? In questo caso può essere un vantaggio strategico
Nel mondo della sicurezza si ripete spesso che la security by obscurity non è sicurezza. In linea di principio è vero: un sistema non dovrebbe essere sicuro solo perché nessuno sa come funziona. Tuttavia, nel contesto specifico della difesa anti-bot, esiste un aspetto pragmatico che non può essere ignorato: l’attaccante sceglie dove investire tempo.
Se una tecnologia come Obscura viene sviluppata per superare o ridurre l’efficacia dei controlli anti-bot, ha senso che i suoi sviluppatori e utilizzatori si concentrino prima sulle piattaforme più diffuse: Cloudflare, Sucuri, Incapsula, Akamai, AWS WAF e in generale i grandi player commerciali. Il motivo è banale: sono il lago con più pesci. Se riesco a trovare una tecnica che funziona contro una soluzione usata da milioni di siti, ho un ritorno enorme. Se invece devo studiare un WAF proprietario, poco diffuso, non documentato pubblicamente e personalizzato per poche migliaia di clienti, lo sforzo diventa molto meno appetibile.
Questo è il punto che molte aziende ignorano quando scelgono una soluzione “di mercato” soltanto perché è il nome più noto. Le piattaforme più diffuse hanno sicuramente enormi capacità, grandi dataset e team di sicurezza dedicati. Ma sono anche il bersaglio naturale di chi sviluppa strumenti anti-detect. Più una difesa è standardizzata e distribuita su larga scala, più diventa interessante studiarla, automatizzarne il bypass e condividerne le tecniche.
Per questo oggi ha molto più senso ragionare anche in termini di diversificazione difensiva. Non perché una soluzione proprietaria sia automaticamente superiore a un grande vendor, ma perché introduce asimmetria. Rompe la prevedibilità. Costringe l’attaccante a misurarsi con logiche, challenge, segnali e regole che non sono documentate, non sono replicabili facilmente e non rappresentano un target economicamente interessante su scala globale.
Perché un WAF proprietario può avere un vantaggio asimmetrico
In Managed Server S.r.l. abbiamo scelto da tempo una strada diversa rispetto all’adozione passiva delle soluzioni più commerciali. Sia chiaro, senza togliere nulla a CloudFlare che a volte ancora utilizziamo. Il nostro approccio è basato su un WAF proprietario sviluppato internamente, WAF 4 NGINX, integrato nella nostra esperienza sistemistica Linux, NGINX, hosting ad alte prestazioni e protezione applicativa.
Nel caso di tecnologie come Obscura, questo approccio ha un valore concreto. Obscura è open source: possiamo studiarne il codice, seguirne l’evoluzione, analizzare cosa viene simulato, quali API vengono imitate, quali segnali vengono mascherati e quali incongruenze restano osservabili. Possiamo costruire test mirati, adattare le regole, sviluppare challenge specifiche e inserire controlli non banali sulla coerenza tra layer di rete, HTTP, JavaScript e comportamento applicativo.
Allo stesso tempo, il codice di WAF 4 NGINX non è pubblico. Questo crea un vantaggio asimmetrico: noi possiamo osservare l’evoluzione di strumenti come Obscura, ma chi sviluppa Obscura non ha accesso al nostro motore di filtering, alle nostre euristiche, alle nostre regole, ai nostri test di coerenza e ai nostri segnali interni. Per studiarli dovrebbe lavorare in black box, provare, fallire, riprovare, dedurre. E dovrebbe farlo per bypassare una tecnologia proprietaria in uso su un numero limitato di installazioni, con un ritorno molto più basso rispetto al bypass di un grande vendor globale come potrebbe essere appunto CloudFlare o Sucuri o Incapsula di IMPERVA.
Questo non è un dettaglio secondario. Nella difesa anti-bot moderna, il costo imposto all’attaccante è una metrica fondamentale. Non esiste protezione assoluta. Esiste però la possibilità di rendere l’attacco meno conveniente, meno replicabile e meno scalabile. Se per superare una protezione comune basta scaricare uno script o usare un profilo già pronto, il costo è basso. Se invece bisogna studiare un ambiente specifico, adattarsi a regole non pubbliche e affrontare controlli personalizzati, il costo cresce.
Cloudflare e il limite della scelta “di mercato”
Cloudflare è una tecnologia importante, matura e largamente adottata. Sarebbe scorretto negarne il valore e soprattutto poco credibile, non vero. Il problema non è Cloudflare in sé. Il problema è l’illusione che scegliere il nome più diffuso equivalga automaticamente a scegliere la protezione migliore per ogni contesto.
Quando tutti consigliano la stessa piattaforma, quando ogni consulente propone la stessa soluzione, quando ogni guida online porta nella stessa direzione, si crea una forma di dipendenza culturale e tecnica. Molti utenti finiscono per credere che “mettere Cloudflare davanti al sito” sia sinonimo di sicurezza completa. Ma i moderni strumenti di automazione non ragionano così. Al contrario: prendono proprio di mira le difese più popolari, perché sono quelle che offrono il maggiore ritorno.
È un po’ lo stesso principio che si osservava negli anni 2000 con i virus informatici. La maggior parte dei malware era sviluppata per PC Windows, non per Linux o macOS. Molti sostenevano che ciò dipendesse dal fatto che Microsoft Windows fosse intrinsecamente meno sicuro, ma la realtà era più pragmatica: Windows era semplicemente il sistema operativo più diffuso e, quindi, il bersaglio più conveniente da attaccare.
Quando anche Apple iniziò a guadagnare quote di mercato e Linux cominciò a diffondersi, seppur in modo molto limitato nel segmento desktop, gli sviluppatori di malware iniziarono a prendere di mira anche macOS e Linux. Non perché prima fossero necessariamente invulnerabili, ma perché fino a quel momento rappresentavano un obiettivo meno interessante dal punto di vista del rapporto tra sforzo e risultato.
Se uno sforzo di ricerca riesce a rendere un headless browser credibile contro una grande piattaforma WAF/CDN usata su larga scala, quel risultato può essere riutilizzato su moltissimi target. E quando il bypass di una soluzione di mercato diventa comune, l’essere “come tutti gli altri” non è più un vantaggio: diventa una superficie prevedibile.
È esattamente qui che una soluzione proprietaria può diventare più interessante. Non perché sia magica, ma perché è meno ovvia. Non perché sia immune, ma perché non è il primo target. Non perché sia segreta e basta, ma perché combina esperienza tecnica, controllo del codice, capacità di adattamento e conoscenza diretta dell’infrastruttura hosting su cui viene applicata.
Obscura non è invincibile: è un motore simulato e lascia segnali
È importante chiarire un punto: Obscura non rende impossibile il rilevamento dei bot. Anzi, il fatto che non sia Chromium può essere sia un vantaggio offensivo sia un punto debole difensivo. Un motore riscritto da zero deve simulare un’enorme quantità di comportamenti del browser reale. Ogni API mancante, ogni valore hardcoded, ogni differenza nel rendering, ogni anomalia tra TLS, HTTP e JavaScript può diventare un segnale.
Un WAF proprietario ben progettato non deve limitarsi a chiedere “questo browser dice di essere Chrome?”. Deve chiedere: il suo TLS è coerente con Chrome? Gli header HTTP sono coerenti con quella versione? Le Client Hints combaciano? Canvas, WebGL, AudioContext e font producono risultati compatibili? Le API meno comuni si comportano come in un browser reale? Il timing degli eventi è plausibile? La sessione mantiene coerenza tra richieste successive? Il comportamento applicativo ha senso rispetto alla pagina visitata?
Questo è il nuovo terreno di gioco. I bot non saranno più bloccati soltanto perché espongono HeadlessChrome nello User-Agent. I WAF efficaci dovranno scendere più in profondità, costruire segnali proprietari, validare la coerenza cross-layer e soprattutto evitare di dipendere esclusivamente da regole generiche già note a chi sviluppa strumenti anti-detect.
La vera lezione per aziende, e-commerce e siti ad alto traffico
La nascita di Obscura è un game changer e un avvertimento per tutto il settore. L’automazione browser sta diventando più economica, più leggera e più accessibile. Gli AI agent aumenteranno il volume di traffico automatico “intelligente”. Lo scraping non sarà più soltanto una questione di script banali, ma di agenti capaci di leggere pagine, comprendere layout, aggirare ostacoli, riprovare strategie e adattarsi.
Per chi gestisce e-commerce, portali editoriali, SaaS, marketplace, aree riservate, API esposte via frontend o siti con contenuti ad alto valore, questo significa una cosa semplice: la protezione standard non basta più. Serve un approccio più specifico, più vicino all’infrastruttura, più integrato con il comportamento reale dell’applicazione.
Un WAF efficace oggi non deve essere solo un elenco di firme. Deve essere un sistema vivo, capace di apprendere dal traffico, distinguere le anomalie, aggiornare i controlli, proteggere le risorse più sensibili e ridurre il rumore senza bloccare utenti legittimi. Deve essere parte dell’architettura, non un adesivo applicato davanti al sito.
È il momento di uscire dal pensiero unico Cloudflare
Se fino ad oggi siete stati affascinati, convinti o persino indottrinati da chi vi raccontava che Cloudflare fosse l’unica scelta sensata, questo è il momento giusto per rimettere in discussione quella convinzione.
Il mercato si muove. Gli strumenti cambiano. Gli AI agent stanno accelerando lo sviluppo di browser headless alternativi. Progetti come Obscura dimostrano che è possibile costruire in tempi relativamente brevi un motore orientato all’automazione, compatibile con gli strumenti esistenti e progettato fin dall’inizio per ridurre la visibilità ai sistemi anti-bot tradizionali.
In questo scenario, scegliere una soluzione proprietaria, sviluppata, controllata e aggiornata internamente, non è una scelta arretrata. È una scelta strategica. Significa non dipendere soltanto da logiche comuni, non essere uguali a milioni di altri siti, non esporre la propria sicurezza alla stessa superficie studiata ogni giorno da chi sviluppa strumenti di scraping e anti-detect.
WAF 4 NGINX nasce proprio da questa filosofia: controllo, adattabilità, performance e difesa mirata. Non una scatola nera generica, ma una tecnologia sviluppata in autonomia, integrata nella nostra esperienza sistemistica e capace di rispondere a minacce reali come Obscura, browser headless avanzati, AI agent e scraping automatizzato.
La sicurezza moderna non è più una questione di brand. È una questione di strategia, conoscenza tecnica e capacità di adattamento. E in un mondo dove anche i bot diventano sempre più intelligenti, essere prevedibili è il primo errore da evitare.
