Il 1 settembre 2026 è stata rilasciata la versione 1.8 di CrowdSec — e nel WAF open-source, che si installa sul proprio server con un solo helm install, sono arrivate due novità: il browser fingerprinting e il proof-of-work. Fino ad ora, il muro PoW si era visto principalmente su git-forge e archivi di mailing list. Ora, uno strato del genere potrebbe trovarsi su qualsiasi sito con cinquecento visitatori al giorno.
Vediamo cosa è cambiato, perché il rilevamento si è orientato verso il "paga con il processore" e — soprattutto — perché l'hash in questa costruzione è il problema minore.
Cosa è successo: il PoW è sceso dai git-forge ai siti normali
CrowdSec è un sistema self-hosted: l'agente legge i log, il WAF si trova davanti all'applicazione e i "bounce" bloccano. Nella versione 1.8, il team ha aggiunto al WAF un meccanismo che non risponde alla domanda "questo IP è cattivo?", ma alla domanda "questo è davvero un browser con una persona o un bot che si finge tale?". La risposta viene raccolta dal fingerprint (caratteristiche del browser e firma TLS) e dal proof-of-work — un compito computazionale che il cliente deve risolvere prima che il backend veda la richiesta.
La motivazione degli autori è formulata senza diplomazia: il bot medio del 2026 arriva con un vero Chrome, un fingerprint TLS consistente, un IP residente — e ha più pazienza di un ingegnere di turno. Questo riconoscimento da parte del rilevamento vale più di qualsiasi analisi: l'indirizzo residente e un TLS accurato hanno smesso di essere un segno distintivo. Poiché, in base alla reputazione IP e alla stretta di mano, il bot non si distingue più dall'uomo, la protezione cerca un segno che sia economico per il browser e costoso per il parco macchine.
Parallelamente, su Hacker News, in quei giorni è emerso POWBlock — "un microservizio proof-of-work per qualsiasi server". Un rilascio può essere considerato una coincidenza, ma due segnali indipendenti in una settimana sono già una direzione.
Come funziona il muro PoW con Anubis come esempio
Il riferimento del genere è Anubis: un reverse proxy in Go sotto licenza MIT, scritto da Xe Iaso per il marchio Techaro dal gennaio 2025. L'idea proviene direttamente dall'hashcash di Adam Back del 1997: il cliente prova valori finché SHA-256 non restituisce un hash con il numero richiesto di zeri iniziali. Se risolvi — ottieni un cookie JWT firmato (techaro.lol-anubis-auth) e accesso temporaneo. Se non risolvi — il backend non saprà nulla di te.
La difficoltà è impostata dall'amministratore. Per impostazione predefinita, Anubis sfida tutto ciò che assomiglia a un browser — cioè tutto ciò che ha nella User-Agent la stringa Mozilla. Quanto costa ogni livello è mostrato dalle misurazioni:
- Difficoltà 1 — meno di 100 ms.
- Difficoltà 4 (predefinita) — circa 1,35 s su Intel Core Ultra 7 165H, che corrisponde a circa 87.600 hash al secondo nel browser.
- Difficoltà 8 — circa 11 s.
- Difficoltà 10 — circa 114 s.
Tra il quarto e il decimo livello, la differenza è di circa 84 volte. L'elenco di chi ha implementato appare impressionante: l'archivio della mailing list del kernel Linux e il server git del kernel, sourcehut, FFmpeg, GitLab del progetto GNOME, Wine, sourceware.org, FreeCAD, ScummVM, Enlightenment, UNESCO. All'università Duke, un pilota nel giugno 2025 ha bloccato più di 4 milioni di richieste HTTP indesiderate al giorno — circa il 90% del traffico spazzatura — e in una settimana 12 persone si sono lamentate di problemi.
Questi muri non sono nati per malizia. Su Read the Docs, un solo crawler ha scaricato 73 TB in un mese; dopo il blocco, il traffico giornaliero è sceso da 800 GB a 200 GB, risparmiando circa 1500 dollari al mese. Drew DeVolt ha descritto come la lotta contro i crawler gli costasse dal 20 al 100 percento di alcune settimane. Sullo sfondo di una crescita del traffico automatizzato del 23,51% nel 2025 e di un quasi triplo aumento del traffico AI nel corso dell'anno, gli amministratori si sono messi a lavorare su ciò che funziona rapidamente.
Un giro di boa: contro il parsing industriale, il PoW funziona quasi nulla
Ora arriva la parte scomoda, che raramente viene scritta nei comunicati stampa. Il proof-of-work si basa sull'asimmetria "economico da verificare, costoso da risolvere". Nel web, questa asimmetria è rivolta nella direzione sbagliata.
Un visitatore onesto calcola gli hash con un JavaScript lento nel browser. Chi è venuto per i dati li considera codice nativo. Tavis Ormandy ha scritto un risolutore in 25 righe di C: un compito di difficoltà 5 si chiude in circa 0,017 secondi — circa 200 volte più veloce del SubtleCrypto del browser. Sul GPU, il divario è ancora maggiore, circa cento volte e oltre. Il risultato dell'aritmetica è semplice: per un grande fornitore, aggirare tutti i siti Anubis costa quasi zero.
Non è teoria. Codeberg già nell'agosto 2025 ha segnalato che molti bot scraper hanno imparato a risolvere le sfide di Anubis. Il muro, però, non è diventato inutile — per alcuni mesi ha bloccato la maggior parte — ma come barriera per chi è disposto a investire una serata in un risolutore nativo, non regge.
Come al solito, a pagare il conto è l'utente reale. La difficoltà 5 richiede circa 2 secondi su un nuovo MacBook, decine di secondi su un vecchio laptop e fino a due minuti su un telefono. Su GitLab GNOME hanno registrato un caso di mezz'ora di blocco su Firefox — un'anomalia, ma indicativa. Inoltre, ci sono eccezioni rigide: per impostazione predefinita, Anubis richiede JavaScript, quindi lettori RSS, curl, wget e Lynx semplicemente non funzionano. Il progetto sta cercando di risolvere questo problema — nella versione 1.20.0 è stato introdotto un percorso senza JS tramite meta-refresh — ma nella 1.22.0 è arrivato il Proof of React, che, al contrario, ha aumentato i requisiti per il browser.
È importante sapere anche della sostenibilità del progetto stesso: circa la metà del codice è committato da una sola persona, e tra gli oltre 80 collaboratori, solo un altro sviluppatore ha superato la decina di commit. Inoltre, in Anubis è integrato un servizio a pagamento Thoth per la filtrazione GeoIP e BGP — cioè, il progetto open-source ha un vicino commerciale.
Dove il PoW morde davvero: la versione commerciale è strutturata diversamente
Qui si nasconde il principale fraintendimento. Kasada, hCaptcha e Cloudflare Turnstile utilizzano anch'essi il proof-of-work — ma non come Anubis.
In Anubis, il puzzle è il muro: esegui JS, calcola l'hash — sei passato. Un segnale, una barriera. Nei sistemi commerciali, il PoW funziona come attestazione. In Kasada, il compito richiede un paio di millisecondi — così pochi che come barriera è privo di senso. Il significato è un altro: per risolverlo, il cliente deve eseguire una macchina virtuale offuscata, all'interno della quale avviene il vero rilevamento. Se calcoli l'hash senza eseguire tutto il resto, non ottieni nulla. hCaptcha sovrappone il PoW al verdetto delle immagini, aumentando il costo computazionale per i clienti sospetti, mentre Turnstile considera il PoW un segnale tra molti altri segnali ambientali.
La differenza è fondamentale. Il muro aperto viene abbattuto da un risolutore nativo economico. Quello commerciale viene abbattuto non dall'hash, ma dalla necessità di eseguire onestamente il codice offuscato di qualcun altro e di non farsi scoprire nell'ambiente — e questo è costoso, perché l'offuscamento viene regolarmente ruotato. CrowdSec 1.8 è interessante proprio perché porta un ibrido di questa logica (fingerprint accanto al PoW) nel mondo self-hosted, dove prima c'era solo un limite di rate per IP.
Cosa cambia nella pratica
Se raccogli dati legalmente — monitorando i prezzi, seguendo il tuo marchio, conducendo ricerche — le conclusioni sono piuttosto concrete.
- Il problema non è nell'hash, ma nel livello del browser. L'hash viene calcolato nativamente in millisecondi. Non viene calcolato il fingerprint, la VM offuscata e l'ambiente corretto. Lo spostamento pratico: dove prima bastava un client HTTP, ora è necessario un vero motore browser. Questo è più costoso in termini di CPU e memoria, e bisogna pianificare subito in base a questo.
- L'economia si sposta dal traffico al tempo e al processore. Prima il costo era calcolato in IP e gigabyte. Ora si aggiungono secondi per pagina e carico dei core. Bisogna misurare non il costo per gigabyte, ma il costo di una registrazione riuscita — con il muro PoW, queste due metriche divergono particolarmente.
- La sessione diventa un attivo. Anubis rilascia un cookie JWT per un certo periodo. Se cambi IP dopo ogni richiesta, paghi nuovamente il "tassa PoW" su ogni pagina. Le sessioni sticky su proxy residenziali qui offrono un vantaggio non in "anonimato", ma direttamente nei calcoli: una soluzione del problema si ammortizza su decine di pagine. La rotazione aggressiva nel mondo PoW si trasforma da buona pratica a sovraccarico.
- Il risolutore non sostituisce il comportamento. La stessa logica per cui i risolutori di captcha hanno smesso di risolvere il problema: risolvi un compito visibile, ma il verdetto è emesso in base a segnali invisibili attorno ad esso.
- Riduci la frequenza — è più economico di qualsiasi muro. L'ondata PoW è cresciuta da storie come 73 TB in un mese da un solo crawler. Cache, richieste condizionali, intervallo ragionevole e rispetto per robots.txt ti tengono lontano dai radar prima che si attivi la sfida. Indirizzi data center economici più headless alla massima frequenza — questo è esattamente il profilo per cui i muri vengono installati.
Conclusione
CrowdSec 1.8 non segna "la fine dello scraping", e Anubis non è diventato tale: un risolutore nativo chiude un compito di difficoltà 5 in 0,017 secondi, mentre una persona reale su un vecchio telefono aspetta fino a due minuti. La vera notizia è un'altra. In primo luogo, il rilevamento ha riconosciuto ad alta voce che l'IP residente e un TLS pulito non dimostrano più nulla. In secondo luogo, lo strato "dimostra di essere un browser" ha smesso di essere un privilegio delle grandi piattaforme con budget per Kasada ed è passato all'open-source, che viene installato su siti normali.
È opportuno prepararsi non a una battaglia con gli hash, ma al fatto che lo schema economico "molti IP più client HTTP veloci" si disintegrerà su obiettivi sempre più piccoli. Vince la configurazione opposta: meno richieste, un vero browser, sessioni lunghe e indirizzi di qualità dove è necessario un passaggio affidabile, non mille tentativi economici.