Il 25 ottobre 2026 un firewall applicativo non diventa un modello linguistico solo perché qualcuno lo chiama AI. Ho riletto la pagina OWASP sul Web Application Firewall, la pagina del Core Rule Set sull’anomaly scoring e la documentazione Cloudflare sull’attack score, aggiornata il 16 aprile 2026. Ho letto gli abstract, non i PDF interi, di due paper su arXiv. Non ho messo un modello in linea e non ho rilanciato i payload.
Il pezzo su cosa un WAF blocca e cosa non risolve resta quello. Qui la domanda è un’altra: con quale criterio la richiesta viene giudicata.
In breve: la pagina OWASP, riletta oggi, definisce il WAF come un firewall per applicazioni HTTP che applica un insieme di regole alla conversazione. In genere quelle regole coprono cross-site scripting e SQL injection. Il CRS esegue regole di rilevazione, somma i match in un punteggio e valuta il blocco dopo, se il punteggio raggiunge una soglia. Cloudflare, nella pagina dell’attack score, descrive un algoritmo di machine learning che assegna un punteggio da 1 a 99 e lo mette accanto alle firme. Quella pagina non lo chiama modello linguistico. I due abstract usano un modello linguistico per generare attacchi e regole, oppure ricordano i buchi delle firme. Non sono lo stesso componente.
Cosa fanno le regole, secondo OWASP e il CRS
La pagina OWASP, il 25 ottobre 2026, dice che un WAF è un firewall applicativo per applicazioni HTTP. Applica un insieme di regole a una conversazione HTTP. In genere quelle regole coprono attacchi comuni come il cross-site scripting e la SQL injection. Un proxy, scrive la pagina, protegge di solito il client. Un WAF protegge il server. Può stare su un appliance, su un plugin o su un filtro, e si personalizza sull’applicazione. La stessa pagina dice che lo sforzo di quella personalizzazione può essere notevole e va mantenuto quando l’applicazione cambia.
La pagina avvisa anche che il contenuto di comunità è stato portato in modo automatico dalla wiki precedente e che il lavoro di sistemazione non è finito. Cito il testo che c’è. Non lo tratto come uno standard chiuso.
Il Core Rule Set, nella pagina sull’anomaly scoring letta lo stesso giorno, descrive un altro pezzo, ancora fatto di regole. L’anomaly scoring, chiamato anche collaborative detection, assegna un punteggio numerico alla transazione HTTP, richiesta e risposta, per quanto appare anomala. La politica di blocco di default, scrive la pagina, blocca la transazione che raggiunge o supera una soglia. Non ho letto su quella pagina il numero della soglia di default, e non lo invento.
Il meccanismo, sempre secondo quella pagina, stacca il rilevamento dal blocco. Le regole che riconoscono tipi di attacco vengono eseguite. Se una regola combacia, non blocca subito. Aggiunge un punteggio alla transazione e di solito scrive un log con l’id della regola, il dato che ha fatto match e l’URI. Quando le regole sulla richiesta hanno finito, si valuta il blocco. È una somma di match. La pagina non descrive un modello linguistico.
Lo score di Cloudflare non è un modello linguistico
La documentazione dell’attack score, aggiornata il 16 aprile 2026 e riletta il 25 ottobre, dice una cosa diversa dalle firme e diversa da un modello linguistico. La classe di rilevamento classifica ogni richiesta con un algoritmo di machine learning e assegna un punteggio da 1 a 99, in base alla probabilità che la richiesta sia malevola. Il rilevamento affianca le WAF Managed Rules.
Le Managed Rules, scrive la stessa pagina, confrontano la richiesta con firme di attacco note, schemi di vettori già visti. La pagina dice che hanno un tasso di falsi positivi molto basso. È una frase loro. In quella frase non c’è un denominatore, e io non l’ho misurato. Subito dopo la pagina dice il limite che interessa qui: un attaccante può modificare un payload noto, per esempio con il fuzzing, e sfuggire al match esatto della firma. L’attack score serve a vedere traffico potenzialmente malevolo che non è un match esatto di nessuna regola delle Managed Rules. Per la protezione massima, la pagina raccomanda di usare entrambi.
La stessa pagina distingue i piani: la funzione completa è per i clienti Enterprise. I piani Business hanno accesso a un solo campo. Non ho aperto il listino e non descrivo prezzi. Non ho nemmeno aperto la sottopagina Available scores. Quello che ho letto basta a non confondere i nomi: machine learning, punteggio 1-99, accanto alle firme. La parola language model, in quella spiegazione, non c’è.
| Cosa | Cosa dice la fonte letta il 25 ottobre 2026 | Cosa non è |
|---|---|---|
| Regole OWASP e CRS | Regole sulla conversazione HTTP. Nel CRS i match sommano un punteggio e il blocco arriva dopo, se si supera una soglia | Non è un modello linguistico. La pagina CRS non lo descrive così |
| Attack score Cloudflare | Algoritmo di machine learning, punteggio da 1 a 99, accanto alle firme. Pagina aggiornata il 16 aprile 2026 | La pagina non lo chiama modello linguistico |
| Modello linguistico, nei due abstract | GenXSS lo usa per generare payload XSS e poi regole. WAPP ricorda i buchi delle firme e il rischio di imparare da traffico avvelenato | Non è un filtro che ho misurato in produzione |
Dove un modello linguistico entra, nei paper
Il primo abstract è GenXSS, arXiv 2504.08176, versione v1 indicata dall’API il 25 ottobre 2026, data di pubblicazione in API 11 aprile 2025. Ho letto l’abstract, non il PDF. L’abstract dice che i WAF tradizionali faticano sugli XSS molto offuscati perché le regole vanno aggiornate a mano. Il framework dichiarato ha due obiettivi: generare payload XSS sofisticati e validati nella sintassi, con un modello linguistico e in-context learning, e automatizzare la difesa provando quegli attacchi contro un’applicazione vulnerabile protetta da un WAF, classificando i bypass e generando regole. L’abstract cita risultati sperimentali con GPT-4o. Non ho riprodotto l’esperimento e non riporto una percentuale che non ho letto per intero.
Il secondo abstract è WAPP, arXiv 2609.06840, versione v1, data in API 6 settembre 2026. Anche qui solo l’abstract. La prima frase è il punto sulle firme: i WAF si appoggiano soprattutto alle signature per gli attacchi noti, e questo può lasciare buchi contro payload modificati o mai visti. La positive security, scrive l’abstract, impara il traffico legittimo e blocca ciò che esce dal profilo. Imparare dal traffico vivo è rischioso se le richieste malevole finiscono nei dati di training. Il framework descritto combina un filtro di fiducia, sintesi deterministica di regole, un punteggio di confidenza e una validazione prima dell’enforcement. Sul campo username di DVWA usato nel test, l’abstract dice che l’apprendimento non filtrato diventa Degraded con lo 0,2% di traffico avvelenato e Broken con lo 0,5%. Vale per quel campo, in quel test. Non è un tasso del tuo sito. L’abstract si interrompe, nella risposta dell’API, mentre parla di un campo di testo libero. Non completo io la frase.
Quindi il modello linguistico, in ciò che ho letto oggi, sta in due posti diversi dal punteggio del CRS e diversi dall’attack score. In GenXSS genera attacchi e proposte di regole. In WAPP il tema è un altro: le firme non vedono il payload nuovo, e imparare dal vivo si può avvelenare. Nessuno dei due abstract è un manuale di deploy. Nessuno dei due l’ho rifatto.
Cosa non cambia
Un criterio nuovo non chiude i lavori vecchi. Le patch restano patch. Una regola, uno score o un modello possono comprare tempo su un payload. Non aggiornano il componente. Il pezzo su cosa un WAF non può risolvere vale anche qui: autorizzazione sbagliata, segreti nel repository, backup mai provato. Una richiesta legale per il filtro può essere tossica per la logica. Non ho riletto quei due articoli riga per riga oggi. Li cito perché l’intento è un altro e non va fuso con questo.
La pagina OWASP, sulla personalizzazione, resta vera qualunque sia il criterio: va mantenuta quando l’applicazione cambia. Uno score lasciato in solo log, o un modello di cui nessuno legge gli errori, è un costo. Non è una riduzione.
Se la richiesta è già passata
Se le firme non hanno matchato e sul server compare un file che esegue comandi, il lavoro non è più “aggiornare la regola in giornata”. Bisogna capire se sul disco c’è già una web shell. La guida pubblicata su KeideaCMS da Marco Artese il 14 aprile 2026, aggiornata l’8 agosto 2026 e ancora online il 25 ottobre, ha una sezione su cosa fare se sospetti che una web shell sia già sul server. Ho letto i titoli delle sezioni e l’apertura dell’articolo. Non ho ricopiato qui i passaggi e non ho verificato i numeri di marketing che compaiono altrove sul sito. La guida non dimostra che un modello linguistico avrebbe fermato quel file. Dice cosa controllare quando il file c’è già.
Errori da evitare
Usare la stessa etichetta per tre meccanismi diversi. La somma dei match del CRS, lo score di machine learning di Cloudflare e un modello linguistico che genera payload non sono la stessa cosa. Le fonti di oggi usano parole diverse.
Spegnere le firme perché c’è uno score. La pagina Cloudflare dell’attack score raccomanda di tenere Managed Rules e score insieme.
Trattare un abstract come un benchmark di produzione. Lo 0,2% e lo 0,5% di WAPP sono il campo username di DVWA in quel test. GenXSS cita GPT-4o. Io non ho rifatto nessuno dei due.
Prendere “falsi positivi molto bassi” come misura mia. È una frase della pagina Cloudflare, senza denominatore in quella frase.
Saltare la patch perché il filtro è “intelligente”. Il componente vulnerabile resta vulnerabile. Il filtro, qualunque criterio usi, non lo aggiorna.
In sintesi
Il 25 ottobre 2026 la pagina OWASP definisce il WAF come regole su una conversazione HTTP, e avvisa che il testo di comunità è un porting ancora da sistemare. Il CRS somma i match e blocca dopo la soglia. Non descrive un modello linguistico. L’attack score di Cloudflare, pagina del 16 aprile 2026, è un algoritmo di machine learning da 1 a 99 accanto alle firme, e la pagina non lo chiama language model. GenXSS, abstract v1, usa un modello linguistico per generare XSS e regole. WAPP, abstract v1, dice che le firme lasciano buchi sui payload nuovi e che imparare dal traffico vivo si avvelena, con lo 0,2% e lo 0,5% limitati al campo username di DVWA che hanno testato. Non ho messo un modello in linea. Il criterio nuovo non sostituisce le patch, né il pezzo già pubblicato su cosa un WAF non risolve.
Foto di copertina: Dr. Marcus Gossler, schedario per soggetto della biblioteca universitaria di Graz, 29 dicembre 2005, Wikimedia Commons, CC BY-SA 3.0. La scheda inquadrata rimanda a Hans Schleimer, che scrisse le regole di quello schedario. È un catalogo, non un firewall.
Fonti
OWASP, Web Application Firewall, letta il 25 ottobre 2026. La pagina dichiara che il testo di comunità è stato portato in automatico e non è sistemato del tutto.
OWASP CRS, Anomaly Scoring, letta il 25 ottobre 2026.
Cloudflare, WAF attack score, last updated 16 aprile 2026, letta il 25 ottobre 2026.
arXiv, GenXSS, 2504.08176v1, abstract via API il 25 ottobre 2026.
arXiv, WAPP, 2609.06840v1, abstract via API il 25 ottobre 2026.
KeideaCMS, guida “Webshell: cos’è, come funziona e come bloccarla”, Marco Artese, 14 aprile 2026, aggiornata l’8 agosto 2026, ancora online il 25 ottobre 2026. L’unico link del pezzo verso quella guida è nel paragrafo “Se la richiesta è già passata”.
