WAF (web application firewall): cos'è e come funziona

Un WAF (web application firewall) è un firewall che lavora sul traffico HTTP e HTTPS di un sito o di un'applicazione web: si mette davanti all'applicazione, legge ogni richiesta e blocca, o segnala, quelle che corrispondono a schemi di attacco noti come la SQL injection e il cross-site scripting. Non sostituisce il firewall di rete né la correzione del codice: riduce l'esposizione mentre il resto si sistema.

Vediamo dove si colloca, come decide cosa bloccare, cosa lascia passare e quando ha senso metterlo in conto.

Cos'è un WAF

La definizione di OWASP, la comunità di riferimento per la sicurezza applicativa, è asciutta: un WAF è "an application firewall for HTTP applications", cioè un firewall applicativo per le applicazioni che parlano HTTP. Applica un insieme di regole alla conversazione HTTP tra il browser (o un client qualsiasi) e il server, di solito tarate su attacchi comuni come cross-site scripting (XSS) e SQL injection.

La stessa pagina OWASP chiarisce il verso: un proxy tradizionale lavora per i client, un WAF lavora per i server. Per questo viene descritto anche come un reverse proxy, un intermediario che riceve le richieste al posto dell'applicazione e le inoltra solo se passano il controllo.

WAF, firewall di rete e IPS: cosa li distingue

• Firewall di rete. Decide in base a indirizzi, porte e protocolli. Il traffico diretto alla porta 443 del sito lo lascia passare, perché è traffico web legittimo.
• IPS (intrusion prevention system). Ispeziona il traffico di rete alla ricerca di firme di attacco su molti protocolli, non solo sul web.
• WAF. Entra dentro la richiesta HTTP: legge URL, parametri, header, cookie e corpo, e li confronta con le sue regole. Vede che il campo "codice cliente" contiene un frammento di query SQL, cosa che il firewall di rete non può vedere.

Sono strati diversi, non alternative: il firewall di rete chiude ciò che non deve essere raggiungibile, il WAF filtra ciò che deve esserlo per forza.

Come funziona un WAF

Dove si installa

Il Virtual Patching Cheat Sheet di OWASP elenca tre forme possibili per lo stesso compito: un dispositivo dedicato (WAF o IPS) posto davanti all'applicazione, un modulo del web server come ModSecurity, oppure un filtro inserito nell'applicazione stessa. A queste si aggiunge il WAF erogato come servizio dal cloud provider o dalla rete di distribuzione dei contenuti, che non richiede apparati in più.

Le regole: modello negativo e modello positivo

Il WAF decide in due modi, descritti nello stesso cheat sheet OWASP:

• Modello negativo (block list): blocca gli schemi di attacco conosciuti. Si mette in funzione in fretta, ma un attaccante che cambia forma al proprio input ha più possibilità di passare.
• Modello positivo (allow list): descrive com'è fatto un input valido (caratteri ammessi, lunghezza, formato) e rifiuta tutto il resto. È il metodo che OWASP raccomanda, ed è anche il più faticoso da mantenere su applicazioni grandi o che cambiano spesso.

Nella pratica si combinano: regole generiche negative su tutto il sito, regole positive mirate sui punti delicati, come il form di pagamento.

Le regole pronte: l'OWASP Core Rule Set

Il riferimento aperto per le regole è l'OWASP CRS (Core Rule Set), che il progetto presenta come un insieme di regole generiche di rilevamento degli attacchi pensate per ModSecurity e per i WAF compatibili. Anche i servizi cloud ci si appoggiano: le regole WAF preconfigurate di Google Cloud Armor sono basate sul CRS, e la documentazione di Google raccomanda la versione 4.22. Le famiglie di attacco coperte danno un'idea del perimetro:

• SQL injection e cross-site scripting;
• inclusione di file locali e remoti (LFI, RFI);
• esecuzione di codice remoto (RCE) e iniezioni specifiche di PHP, Java e Node.js;
• attacchi al protocollo HTTP, metodi non ammessi, fissazione della sessione;
• rilevamento degli scanner automatici;
• regole dedicate a singole vulnerabilità note, come quella di Log4j.

Ogni regola può fermare la richiesta oppure lasciarla passare e registrare un allarme. Un WAF in sola segnalazione serve solo se qualcuno legge quelle segnalazioni: ci torniamo in chiusura.

Cosa ferma e cosa lascia passare

Un WAF funziona contro gli attacchi che si riconoscono dalla forma della richiesta: injection, tentativi di leggere file di sistema, sonde automatiche. È cieco su ciò che sembra una richiesta normale.

Il caso più importante è il controllo degli accessi. Nell'edizione 2025 del Top 10 di OWASP la prima posizione è di Broken Access Control (A01:2025): un utente autenticato che cambia un identificativo nell'URL e legge l'ordine di un altro cliente invia una richiesta sintatticamente perfetta. Non c'è niente di sospetto nella forma, è il controllo di autorizzazione che manca nel codice. Lo stesso vale per i difetti di logica di business (applicare due volte uno sconto, saltare un passaggio di approvazione) e per l'uso di credenziali rubate ma valide.

OWASP lo scrive in modo esplicito parlando di virtual patching: la regola riduce l'esposizione solo per il traffico che il WAF ispeziona e per le varianti di attacco che le sue regole riconoscono, e non elimina la vulnerabilità sottostante. Per sapere dove stanno i difetti che il WAF non vede serve un web application penetration test, che lavora proprio sull'area autenticata e sulle autorizzazioni.

Virtual patching: comprare tempo quando il codice non si può correggere subito

Uno degli usi più concreti di un WAF è il virtual patching. OWASP lo definisce come un livello di controllo che rileva e blocca i tentativi di sfruttare una vulnerabilità nota senza modificare il codice vulnerabile. Serve quando la correzione vera richiede tempo: software di terze parti in attesa della patch del fornitore, sviluppo esternalizzato, un'applicazione che nessuno sa più modificare.

Le avvertenze di OWASP sono tre:

• la toppa virtuale non chiude il problema: la correzione del codice o del fornitore va portata avanti in parallelo;
• bloccare solo il payload esatto del report dà un rimedio immediato ma di poco valore nel tempo, perché basta una variante per aggirarla;
• le regole vanno provate prima in sola registrazione, per verificare che non blocchino il traffico legittimo, e poi messe alla prova contro i tentativi di aggiramento.

Il virtual patching si inserisce quindi in un processo di patch management, non lo sostituisce.

Falsi positivi e taratura: il lavoro che non finisce

Un WAF troppo permissivo lascia passare gli attacchi, uno troppo severo blocca i clienti. Il CRS gestisce questo equilibrio con quattro paranoia level: ogni livello aggiunge regole al precedente, il livello 1 è la base per chiunque abbia un server HTTP su internet e richiede poca taratura, il livello 2 è indicato quando passano dati reali degli utenti (il progetto fa l'esempio di un negozio online), il livello 4 è pensato per i sistemi più critici e comporta molti falsi positivi. Più si sale, più è difficile passare inosservati, e più richieste legittime vengono scambiate per attacchi. I falsi positivi si eliminano con esclusioni mirate delle regole.

Google Cloud Armor espone lo stesso concetto come livello di sensibilità, che corrisponde al paranoia level del CRS: per impostazione predefinita valuta tutte le firme fino al livello 4. Chi attiva le regole senza tararle deve quindi mettere in conto blocchi su richieste legittime.

Due accorgimenti pratici, entrambi da OWASP:

• si parte in sola registrazione, si osserva il traffico reale e solo dopo si passa al blocco, con criteri di monitoraggio e di ritorno indietro definiti prima;
• i log del WAF possono contenere password e dati di pagamento, perché registrano le richieste: i campi sensibili vanno esclusi o mascherati prima di salvarli.

E la taratura non si fa una volta sola: OWASP nota che personalizzare le regole richiede un impegno significativo, da mantenere a ogni modifica dell'applicazione.

Quando serve un WAF, e cosa chiedono le regole

Lo standard che lo chiede quasi per nome: PCI DSS

Chi tratta dati di carte di pagamento ha un requisito preciso. Il PCI DSS, al requisito 6.4.2 introdotto con la versione 4.0 (oggi in vigore nella revisione 4.0.1, che non ha aggiunto né tolto requisiti), chiede per le applicazioni web esposte al pubblico uno strumento tecnico automatico che rilevi e prevenga in modo continuo gli attacchi web, con almeno quattro caratteristiche: installato davanti all'applicazione, attivo e aggiornato, in grado di generare log di audit, configurato per bloccare gli attacchi oppure per generare un allarme indagato immediatamente. Il requisito è obbligatorio dal 31 marzo 2025 e sostituisce il 6.4.1, che ammetteva in alternativa la revisione periodica delle applicazioni. Il testo non nomina un prodotto, ma nella versione 3.1 il requisito che lo precedeva, il 6.6, che ammetteva la stessa alternativa del 6.4.1, indicava come esempio dello strumento automatico proprio il web application firewall.

NIS2 e D.Lgs. 138/2024: nessuno strumento per nome

Il D.Lgs. 138/2024, che recepisce la NIS2, non nomina il WAF. L'art. 24 chiede misure tecniche, operative e organizzative adeguate e proporzionate, che tengano conto dello stato dell'arte, e tra gli elementi minimi elenca la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi, compresa la gestione delle vulnerabilità (lettera e), e le procedure per valutare l'efficacia delle misure (lettera f). Per chi ha applicazioni esposte, un WAF è uno dei modi per dare sostanza alla lettera e, insieme ai test e alla correzione del codice. Il quadro completo è nella guida alla NIS2.

I casi in cui ripaga

• E-commerce e portali con pagamenti, per il requisito PCI e perché sono bersagli diretti.
• Portali clienti e aree riservate che espongono dati personali o documenti.
• Applicazioni di terze parti o datate, dove la patch del codice non dipende da te o richiede settimane: è il terreno del virtual patching.
• API pubbliche aperte a partner o app mobili, che sono traffico HTTP a tutti gli effetti.

Ha meno senso come prima voce di spesa per un sito vetrina statico, senza form né aree autenticate.

Un WAF senza qualcuno che legge i log è mezzo WAF

Il requisito PCI contiene un'indicazione che vale per tutti: se il WAF non blocca, l'allarme va indagato subito. Preso da solo, un evento del WAF dice poco. Il segnale utile è quello che si collega ad altro: lo stesso indirizzo che prova una SQL injection e poi effettua un login riuscito, un picco di richieste bloccate su un endpoint subito dopo la pubblicazione di una vulnerabilità.

Per vederlo, i log del WAF devono arrivare dove si correlano con quelli dei sistemi di autenticazione, dei server e degli endpoint, cioè in un SIEM con qualcuno che lo presidia. E la configurazione del WAF va verificata nel tempo: un penetration test dice cosa passa nonostante il filtro, una scansione periodica (vulnerability assessment) dice quali vulnerabilità note sono rimaste aperte e richiedono una regola o una patch.

Il WAF riduce l'esposizione, il monitoraggio riduce il tempo in cui un attacco riuscito resta inosservato. AmagisTech lavora con il mid-market italiano sul secondo fronte, con un servizio di detection e response gestito: se vuoi capire cosa succede oggi davanti alle tue applicazioni web, trovi come lavoriamo nella pagina sulla cybersecurity gestita.