Il Web Application Firewall, comunemente indicato come WAF, è un componente di sicurezza progettato per analizzare e filtrare il traffico HTTP e HTTPS diretto verso applicazioni web. A differenza di un firewall di rete tradizionale, che opera principalmente a livello di indirizzi IP, porte e protocolli, un WAF analizza il contenuto delle richieste HTTP cercando comportamenti e pattern associati a tentativi di attacco contro l'applicazione. Il suo posizionamento avviene normalmente davanti ai server web o agli application server, spesso attraverso un'architettura reverse proxy, permettendo di intercettare le richieste prima che raggiungano l'applicazione. Questa caratteristica rende il WAF particolarmente importante per proteggere portali web, e-commerce, API, applicazioni gestionali accessibili da Internet e servizi esposti pubblicamente.

Come funziona un WAF

Il funzionamento di un Web Application Firewall parte dall'intercettazione della richiesta HTTP o HTTPS proveniente dal client. Il WAF analizza elementi come metodo HTTP, URL, query string, header, cookie, parametri, body della richiesta e indirizzo IP del client. In base alle policy configurate, la richiesta può essere autorizzata, registrata, limitata oppure bloccata prima di essere inoltrata al server web.

In una configurazione reverse proxy, il client non comunica direttamente con il server applicativo. La connessione viene stabilita verso il WAF, che successivamente crea una seconda connessione verso il backend. Questo modello permette di centralizzare il controllo del traffico e di nascondere l'infrastruttura interna, riducendo l'esposizione diretta degli application server.

WAF e firewall tradizionale

Un firewall tradizionale opera principalmente a livello di rete e trasporto, controllando elementi come indirizzi IP, porte, protocolli e connessioni. Un WAF lavora invece a un livello applicativo superiore e interpreta il traffico HTTP.

Una connessione TCP sulla porta 443 può essere perfettamente valida dal punto di vista del firewall di rete e contenere comunque una richiesta HTTP malevola. Un attaccante potrebbe utilizzare una connessione HTTPS apparentemente normale per inviare una SQL Injection, un Cross-Site Scripting o una richiesta progettata per sfruttare una vulnerabilità dell'applicazione. Il firewall di rete non necessariamente dispone delle informazioni necessarie per riconoscere il contenuto dell'attacco, mentre il WAF può analizzare la richiesta HTTP dopo la terminazione TLS.

Filtraggio HTTP e HTTPS

Il WAF può analizzare sia traffico HTTP sia HTTPS. Nel caso di HTTPS è necessario che il dispositivo o servizio WAF effettui la terminazione TLS, perché il contenuto della richiesta è cifrato durante il trasporto. Dopo aver stabilito la sessione TLS con il client, il WAF può decifrare la richiesta, applicare le proprie regole e successivamente inoltrare il traffico al backend attraverso una nuova connessione.

La comunicazione tra WAF e server applicativo può a sua volta utilizzare HTTPS, soprattutto quando i sistemi sono distribuiti su reti differenti o quando i dati trattati sono sensibili. In questo caso la cifratura viene mantenuta anche nel collegamento interno. È importante gestire correttamente certificati, versioni TLS, cipher suite e verifica dei certificati utilizzati tra i diversi componenti.

Protezione contro SQL Injection

Uno dei principali utilizzi del WAF è il rilevamento di richieste riconducibili a SQL Injection. L'attaccante può tentare di manipolare parametri HTTP per modificare il comportamento di una query SQL eseguita dall'applicazione. Un WAF può riconoscere pattern tipici di payload malevoli e bloccare la richiesta prima che raggiunga il backend.

La protezione WAF non sostituisce però Prepared Statements, query parametrizzate e corretta gestione dell'input nell'applicazione. Se il codice PHP, Java, .NET o qualsiasi altro ambiente applicativo costruisce query SQL in modo insicuro, il problema deve essere corretto direttamente nel software. Il WAF rappresenta una misura di difesa aggiuntiva che può ridurre il rischio di sfruttamento, ma non deve diventare l'unico livello di protezione.

Protezione contro Cross-Site Scripting

Il WAF può inoltre identificare richieste contenenti pattern associati a Cross-Site Scripting, attraverso l'analisi di parametri, query string e contenuto della richiesta. L'obiettivo è impedire che payload JavaScript malevoli raggiungano l'applicazione quando vengono utilizzati per sfruttare vulnerabilità di input o output.

Anche in questo caso la protezione principale deve essere implementata a livello applicativo attraverso validazione dell'input, output encoding, Content Security Policy e corretta gestione dei dati provenienti dall'utente. Il WAF aggiunge un ulteriore livello di filtraggio e può risultare particolarmente utile quando esistono applicazioni legacy che non possono essere immediatamente riscritte.

OWASP Core Rule Set

Molti WAF possono utilizzare il ModSecurity Core Rule Set, noto come OWASP CRS, come base per le regole di rilevamento. Il CRS contiene regole generiche progettate per identificare numerose categorie di attacchi web e viene frequentemente utilizzato insieme a ModSecurity.

Le regole possono analizzare differenti componenti della richiesta e attribuire un punteggio di anomalia in base alle corrispondenze rilevate. Questo approccio permette di evitare che ogni singolo pattern debba necessariamente determinare un blocco immediato. Quando vengono rilevati più indicatori sospetti, il punteggio complessivo può superare una determinata soglia e provocare il blocco della richiesta.

Detection e Blocking Mode

Un WAF può generalmente operare in modalità di rilevamento oppure in modalità di blocco. In modalità di rilevamento le richieste sospette vengono registrate senza essere necessariamente rifiutate. Questa configurazione è particolarmente utile durante la fase iniziale di implementazione perché permette di osservare il comportamento dell'applicazione e individuare eventuali falsi positivi.

La modalità di blocco applica invece effettivamente le policy di sicurezza. Passare direttamente al blocco senza una fase di analisi può provocare problemi applicativi, soprattutto quando l'applicazione utilizza parametri complessi, JSON, upload di file, query particolari o funzionalità non previste dalle regole generiche. Una configurazione professionale richiede quindi una fase di tuning delle policy prima dell'applicazione restrittiva delle regole.

False positive e tuning delle regole

Uno dei problemi più importanti nella gestione di un WAF è rappresentato dai falsi positivi. Una richiesta legittima può contenere una sequenza di caratteri che assomiglia a un payload malevolo e venire quindi classificata erroneamente come attacco.

Questo problema è particolarmente frequente nelle applicazioni che gestiscono JSON complessi, editor HTML, filtri avanzati, contenuti tecnici, file caricati dagli utenti o parametri molto lunghi. Per ridurre i falsi positivi è necessario analizzare i log, identificare la regola che ha generato l'evento e creare eccezioni mirate invece di disabilitare indiscriminatamente intere categorie di protezione. Un'eccezione dovrebbe essere il più possibile specifica per endpoint, parametro o condizione, mantenendo attive le altre protezioni.

Rate Limiting

Il WAF può essere utilizzato anche per controllare la quantità di richieste ricevute dall'applicazione. Il rate limiting permette di limitare il numero di richieste provenienti da uno specifico indirizzo IP, client, API key o altro identificativo.

Questa funzione è utile contro attività automatizzate, scraping aggressivo, tentativi ripetuti di autenticazione e alcune forme di abuso delle API. Il limite deve però essere configurato considerando il comportamento reale dell'applicazione. Un portale pubblico e un endpoint amministrativo possono richiedere soglie completamente differenti. Una configurazione troppo aggressiva può infatti bloccare anche utenti legittimi.

Protezione dei server backend

Una corretta architettura WAF dovrebbe impedire ai client Internet di raggiungere direttamente i server applicativi. Se l'indirizzo IP del backend rimane pubblicamente accessibile, un attaccante potrebbe bypassare il WAF e inviare le richieste direttamente al server.

Il firewall interno dovrebbe quindi consentire il traffico verso il web server soltanto dagli indirizzi utilizzati dal WAF o dal reverse proxy autorizzato. Questa configurazione crea una vera separazione tra il livello pubblico e quello applicativo. L'efficacia del WAF dipende infatti anche dalla capacità dell'infrastruttura di impedire il bypass del punto di controllo.

Header HTTP e sicurezza

Il WAF può controllare e modificare alcuni header HTTP e contribuire alla gestione di policy di sicurezza. Header come Host, Content-Type, User-Agent, X-Forwarded-For e altri elementi possono essere utilizzati per applicare regole di filtraggio e logging.

Particolare attenzione deve essere dedicata agli header che identificano l'indirizzo IP originale del client. Quando il traffico passa attraverso proxy o bilanciatori, l'applicazione può ricevere l'indirizzo del proxy anziché quello reale dell'utente. Header come X-Forwarded-For devono quindi essere gestiti soltanto quando provengono da proxy considerati affidabili, evitando di utilizzare direttamente valori forniti dal client come se fossero attendibili.

Protezione delle API

Le API rappresentano uno degli scenari nei quali il WAF può avere un ruolo importante. Un'applicazione moderna può esporre numerosi endpoint utilizzati da frontend, applicazioni mobili, sistemi esterni e servizi aziendali. Il WAF può controllare metodo HTTP, endpoint, content type, dimensione delle richieste e pattern presenti nei payload.

Nel caso di API JSON è possibile applicare policy specifiche per evitare richieste eccessivamente grandi, metodi HTTP non previsti o parametri anomali. L'autenticazione e l'autorizzazione devono comunque essere gestite correttamente dall'applicazione o dall'API Gateway, perché il WAF non sostituisce il controllo dei permessi associati all'utente.

Logging e analisi degli eventi

Ogni richiesta bloccata o classificata come sospetta dovrebbe essere registrata con informazioni sufficienti per effettuare un'analisi tecnica. I log possono contenere timestamp, indirizzo IP, URL richiesto, metodo HTTP, codice di risposta, regola attivata e identificativo della richiesta.

Questi dati possono essere inviati a un sistema centralizzato di logging o a un SIEM, permettendo di correlare gli eventi del WAF con quelli provenienti da firewall, server, endpoint e applicazioni. Una serie di richieste bloccate verso lo stesso endpoint può, ad esempio, essere correlata con tentativi di autenticazione falliti o con attività anomale rilevate dal sistema operativo.

È importante evitare di registrare nei log password, token completi, cookie di sessione o altri dati sensibili non necessari. La raccolta deve essere sufficientemente dettagliata per l'analisi senza trasformare il sistema di logging in una nuova fonte di esposizione dei dati.

WAF e DDoS

Un WAF può contribuire alla gestione di determinati attacchi applicativi, ma non deve essere considerato una protezione completa contro ogni forma di DDoS. Un attacco volumetrico può saturare la connettività o le risorse a monte dell'infrastruttura prima che il traffico raggiunga il WAF.

Per questo motivo, quando l'applicazione è particolarmente esposta, il WAF può essere integrato con sistemi di mitigazione DDoS, CDN, load balancer e servizi di protezione distribuiti. Il WAF rimane responsabile principalmente dell'analisi del traffico applicativo e del filtraggio delle richieste HTTP, mentre altri livelli possono gestire la capacità di assorbire grandi volumi di traffico.

WAF on-premise e WAF cloud

Un WAF può essere installato direttamente nell'infrastruttura aziendale oppure erogato come servizio cloud. Un WAF on-premise offre un controllo diretto sull'infrastruttura e può essere integrato strettamente con firewall, reverse proxy e sistemi locali. Un WAF cloud può invece offrire una maggiore distribuzione geografica e una capacità di gestione del traffico più elevata, soprattutto quando viene integrato con una CDN.

La scelta dipende dall'architettura applicativa, dal volume di traffico, dai requisiti di sicurezza, dalla distribuzione geografica degli utenti e dalla necessità di mantenere l'infrastruttura internamente. In entrambi i casi è fondamentale che il WAF venga configurato in modo coerente con l'applicazione e non semplicemente attivato utilizzando regole generiche.

WAF e applicazioni legacy

Il WAF può essere particolarmente utile nella protezione di applicazioni legacy che non possono essere aggiornate rapidamente. Un software sviluppato anni prima può utilizzare framework obsoleti, librerie non più supportate o componenti difficili da modificare. Il WAF può introdurre un livello aggiuntivo di protezione mentre viene pianificata la modernizzazione dell'applicazione.

Questo approccio non deve però trasformarsi in una giustificazione per mantenere indefinitamente software vulnerabile. Il WAF riduce il rischio di esposizione ma non elimina la vulnerabilità presente nel codice. La soluzione definitiva rimane la correzione dell'applicazione o la sostituzione del componente obsoleto.

Alta disponibilità del WAF

Il WAF stesso rappresenta un componente critico e deve essere progettato evitando un singolo punto di guasto. In un ambiente aziendale ad alta disponibilità è possibile utilizzare più istanze WAF, sistemi di bilanciamento e configurazioni ridondate.

La disponibilità deve essere considerata anche durante gli aggiornamenti delle regole. Una modifica errata può bloccare un'applicazione intera, mentre un malfunzionamento del servizio può impedire agli utenti di raggiungere i sistemi protetti. Per questo motivo le modifiche alle policy devono essere sottoposte a test e, quando possibile, introdotte progressivamente.

Il Web Application Firewall rappresenta quindi un livello fondamentale della sicurezza applicativa perché permette di analizzare il traffico HTTP e HTTPS prima che raggiunga i sistemi backend. Attraverso reverse proxy, terminazione TLS, regole applicative, analisi dei payload, rate limiting, logging e integrazione con sistemi di sicurezza, il WAF può ridurre significativamente la superficie di attacco delle applicazioni esposte su Internet. La sua efficacia dipende però dalla qualità della configurazione: regole troppo permissive possono lasciare passare traffico malevolo, mentre policy eccessivamente aggressive possono generare falsi positivi e interrompere funzionalità legittime. Un WAF correttamente progettato deve quindi essere integrato con firewall, sistemi di autenticazione, API Gateway, application security, monitoraggio e gestione dei log. Deve inoltre essere sottoposto a continuo tuning in funzione dell'evoluzione dell'applicazione e delle nuove tecniche di attacco. Il WAF non sostituisce la sicurezza del codice, ma aggiunge un ulteriore livello di difesa capace di intercettare e filtrare richieste anomale prima che raggiungano l'applicazione, rendendo l'infrastruttura web più controllabile, monitorabile e resistente agli attacchi applicativi.