Il WAF è un filtro, non una toppa sul codice. Serve quando sai cosa vuoi bloccare. Non serve come scusa per non patchare.
Un WAF filtra richieste HTTP. Non riscrive il codice, non autentica al posto tuo, non tiene i backup, non chiude una CVE nel plugin. Serve quando sai quale classe di traffico vuoi fermare prima che arrivi all'applicazione. Non serve come scusa per non patchare, e non è un antivirus del sito. Se lo tratti come toppa sul software, scopri i limiti il giorno in cui una richiesta "legale" per il filtro è comunque tossica per la logica di business.
In breve: il Web Application Firewall ispeziona e può bloccare, rate-limitare o loggare il traffico web secondo regole. Copre una parte dei rischi elencati nell'OWASP Top 10, soprattutto ciò che si vede sulla rete. Non copre autenticazione disegnata male, autorizzazioni sbagliate, segreti in repo, dipendenze vecchie. Si aggiunge. Non sostituisce.
Cosa trovi in questo articolo
Cosa è, e cosa filtra
Un WAF sta sul percorso HTTP, in linea o in reverse proxy. Vede metodo, URL, header, corpo, a volte cookie e sessioni. Confronta con un insieme di regole: firme di attacco note, anomalie, liste, limiti di frequenza, geo, reputazione. Può far passare, bloccare, mettere in challenge, solo registrare. È un filtro di applicazione web. Non è un firewall di rete, non è protezione DDoS volumetrica, non è un IDS sul sistema operativo.
Il valore, quando c'è, è tempo e superficie. Tempo: una classe di exploit noti si può intercettare mentre patchi. Superficie: riduci il rumore di scanner e di payload ovvi che altrimenti finiscono nei log dell'applicazione. Il costo è falso positivo, complessità, e l'illusione di aver "messo la sicurezza". L'illusione è la parte cara.
OWASP tiene una scheda di comunità sul Web Application Firewall: è un controllo, con limiti, non un prodotto magico. Lo stesso tono vale in redazione. Il cluster Sicurezza tiene insieme patch, TLS, WAF. L'ordine non è casuale. Il certificato e le patch vengono prima. Il filtro, dopo, se manca un pezzo o se il rischio residuo lo giustifica.
OWASP Top 10: dove arriva, dove no
L'OWASP Top 10 è una mappa di rischi applicativi, non una checklist del WAF. Alcune voci si vedono in chiaro sul filo HTTP: injection visibili in query e body, request che tentano path noti, header grotteschi. Altre vivono nel disegno: broken access control, fallimenti crittografici, componenti vulnerabili già dentro il runtime, logging insufficiente. Un filtro può aiutare sulle prime. Sulle seconde, no, o solo di striscio.
Esempio utile, senza teatrini di percentuale di blocco (non ne inventiamo). Una SQL injection classica in un parametro GET è il tipo di cosa che una ruleset matura tenta di cogliere. Un endpoint che restituisce l'ordine di un altro utente perché l'ID è un intero incrementale e manca un controllo di proprietà: quella richiesta è HTTP legale, autenticata, senza payload "brutto". Il WAF la lascia passare. Era un bug di autorizzazione. Si sistema nel codice.
Stesso discorso per XSS riflesso contro XSS derivato da un dato già in database, per un CSRF su un form che il filtro non capisce, per un file upload che passa i mime e poi viene eseguito perché l'applicazione lo mette in una directory sbagliata. Il Top 10 serve a ragionare sul rischio. Non a comprare un box.
Regole e motori, ModSecurity compreso
Sotto i prodotti commerciali e sotto parecchie installazioni in proprio c'è un motore di regole. ModSecurity è uno di questi, oggi progetto OWASP, usato da anni davanti ad Apache, Nginx e altri reverse proxy. Non è l'unico. È la prova che il WAF, in sé, è un engine più un set di regole più una politica di cosa fare in caso di match. Senza politica, è un generatore di log.
Le regole si sintonizzano. Fuori dalla scatola, su un'applicazione reale, producono falsi positivi: un editor che salva HTML, un webhook con payload strano, un'API che parla un dialetto. Se lasci tutto in blocking senza guardare, rompi il sito e qualcuno disattiva il WAF. Se lasci tutto in detection per sempre, hai un costo e nessuna riduzione. Il mestiere è: detection, revisione, poi blocking selettivo su ciò che hai capito. Non il contrario.
Niente tassi di blocco da brochure. Un numero del genere dipende dal traffico, dalle regole, dal sito. Citato senza contesto è pubblicità. In redazione non lo usiamo.
Cosa non può risolvere
Non sostituisce le patch di sicurezza. Una CVE in un plugin resta una CVE. Il WAF può, a volte, comprare ore o giorni con una regola virtual patch. Ore. Non un trimestre. La correzione è aggiornare o togliere il pezzo.
Non sostituisce il disegno di autenticazione e di sessione. Password deboli, reset fatti male, cookie senza attributi, mancanza di MFA dove servirebbe: il filtro vede richieste, non il tuo modello di identità. TLS e HSTS sono un altro strato, trattato in HTTPS e HSTS. Un WAF in HTTP chiaro su un sito che mescola contenuti è un oggetto messo nel posto sbagliato.
Non è un backup. Se qualcuno entra, o se un'operazione legittima cancella i dati, il WAF non ripristina. Non è nemmeno, da solo, una difesa DDoS. Un attacco volumetrico si gioca sulla rete, prima dell'HTTP. Un attacco applicativo fatto di richieste "valide" ma numerose può essere fatto oggetto di rate limit nel WAF, e anche lì i tetti si calibrano. Il confine tra volume e applicazione sta in protezione DDoS e hosting.
Mettere in opera regole, eccezioni e logging non è un pomeriggio. Se il team interno non ha ore per sintonizzare, il lavoro è di applicazione e di esercizio, non di "accendere il prodotto". In quel caso si cerca chi sa leggere sia il filtro sia il codice. Tra chi fa sviluppo e messa in sicurezza applicativa in Italia ci sono anche i servizi di sviluppo web di Keidea. Non vendono "un WAF". È il tipo di lavoro che chiedi quando il filtro va agganciato a un'applicazione vera, con eccezioni vere, e qualcuno deve restare a occuparsi dei falsi positivi dopo il go-live.
Ha senso quando. Non serve quando
Ha senso quando esponi un'applicazione con una superficie HTTP ampia, quando vuoi una rete di contenimento mentre patchi, quando il rumore di scanner ti costa sui log e sull'origine, quando hai qualcuno che legge gli allarmi. Ha senso in detection anche solo per vedere cosa ti arriva, se poi agisci.
Non serve come primo controllo su un sito che non aggiorni, con admin esposto, con plugin abbandonati. Stai mettendo una tenda davanti a una porta aperta. Non serve su un'applicazione minuscola, già dietro autenticazione forte e rete ristretta, se il costo di sintonizzare le regole supera il rischio. Non serve "perché lo hanno messo in capitolato" se poi sta in log-only per sempre e nessuno apre i log.
Ha senso integrarlo con gli altri controlli, non in sostituzione. Patch, privilegi minimi, backup provati, TLS in ordine, monitoring. Il WAF è una riga. Se è l'unica riga, è teatro.
Errori da evitare
Accendere il blocking il primo giorno su un sito in produzione. Prima si osserva. Poi si stringe. Altrimenti il WAF diventa "quello che ha rotto il checkout".
Trattare una virtual patch come correzione. È un prestito di tempo. Si restituisce con l'update.
Non avere un canale per i falsi positivi. Il commerciale che non può inviare un form è un incidente di prodotto, non un successo di sicurezza.
Confondere WAF e protezione volumetrica. Saturare la linea a layer 3 è un altro mestiere.
Lasciare l'admin sulla rete pubblica "perché c'è il WAF". L'admin si chiude, si mette su VPN o su allowlist. Il filtro è extra, non recinto.
Citare percentuali di attacchi bloccati senza denominatore. Senza traffico di riferimento, è un numero vuoto.
In sintesi
Il WAF è un filtro HTTP. Può fermare una parte di ciò che l'OWASP Top 10 rende visibile sulla rete. Non può fare le patch, non può disegnare l'autorizzazione, non può tenerti una copia dei dati. ModSecurity e i ruleset analoghi sono motori, da sintonizzare. Detection, poi blocking. Virtual patch, poi update. Se ti serve qualcuno per agganciarlo all'applicazione, è lavoro di implementazione, non un prodotto da spuntare. Meno rumore, più metodo: il filtro dopo i controlli che il filtro non sa fare.
Fonti
OWASP, OWASP Top 10.
OWASP, Web Application Firewall (scheda di comunità).
OWASP, ModSecurity.
Nessun tasso di blocco, nessun confronto di vendor e nessun prezzo è usato come prova in questo pezzo.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
