Il Web Application Firewall (WAF) è uno di quegli strumenti di cui si parla spesso, ma che si sfrutta raramente al suo pieno potenziale. In molti casi, viene installato frettolosamente, attivato con regole predefinite, e poi lasciato lì come un semplice scudo passivo.
Questo post del blog ha l'obiettivo di spiegare come ottenere il massimo da un WAF : comprendere cosa fa realmente, stimare il suo costo complessivo, evitare gli errori comuni e, soprattutto, costruire un approccio misurabile alla sua efficacia.
Perché e quando utilizzare un WAF ?
Un WAF diventa indispensabile non appena un'applicazione web gestisce dati sensibili (account cliente, pagamento, salute), espone API critiche (mobile, partner, back-office), è soggetta a requisiti di conformità (PCI-DSS, RGPD) o subisce attacchi ricorrenti (credential stuffing, bots, scans aggressivi). I suoi usi tipici includono :
la riduzione dell'esposizione alle vulnerabilità del Top 10 OWASP (iniezioni, XSS, RCE),
il virtual patching per mitigare un zero-day o una patch applicativa in sospeso,
la difesa contro i bots (scraping, acquisizione di account, volumetria anomala sugli endpoints sensibili).
Al contrario, su un sito puramente statico servito da un CDN, un WAF apporta poco valore e può persino aggiungere latenza se mal configurato. Il contesto deve quindi dettare il suo utilizzo : valore aziendale degli endpoints, sensibilità dei dati, esposizione a terzi e maturità del team.
Le sezioni che seguono rispondono alle tre sfide chiave : posizionare correttamente il WAF nell'infrastruttura, scegliere una soluzione adatta al costo e alle esigenze, e adottare un approccio attivo piuttosto che “bloccare tutto per impostazione predefinita”.
Che cos'è un WAF ?
Tecnicamente, un Web Application Firewall è un componente che agisce sul livello 7 del modello OSI (ossia il livello applicativo), intercetta il traffico HTTP(S) e decide, per ogni richiesta, se :
autorizzarla,
bloccarla,
sfidarla (CAPTCHA, challenge JavaScript),
o contrassegnarla per l'ispezione (stato “Counted” su AWS).
I motori moderni combinano diversi segnali :
Firme classiche (patterns di iniezioni SQL, XSS, ecc.),
Euristiche e comportamento (tasso di richieste, anomalie negli headers, payloads atipici),
Reputazione (IP note per la scansione o l'attacco, Tor, proxys, ecc.),
Contesto (paese, autonomous system (AS), User-Agent, cookie, session).
Un WAF efficace non è solo un motore di regole, il team responsabile di questo componente di sicurezza deve essere in grado di :
Riconoscere un reale tentativo di attacco da parte di un attore malevolo in mezzo al rumore degli scans automatici,
Intraprendere azioni difensive in base all'andamento del traffico sull'applicazione,
Far evolvere continuamente la politica di filtraggio sulla base del feedback e dei falsi positivi rilevati in produzione.
Dove posizionarlo nell'infrastruttura ?
È soprattutto qui che è possibile rovinare l'efficacia di un WAF. La posizione del WAF nella tua architettura determina sia le sue prestazioni che la sua efficacia.
Opzione 1 : WAF sul CDN
In alcuni progetti, il WAF è semplicemente innestato sul livello CDN (esempio AWS qui sotto) :
È pratico e veloce, ma è una falsa buona idea :
Le regole vengono applicate a tutto il traffico CDN, inclusi gli asset statici,
Certe regole (ispezione profonda, regex pesanti) possono ridurre, talvolta completamente, l'efficacia della cache,
I veri attacchi interessanti raramente mirano a /assets/smile.webp, ma piuttosto agli endpoints di API.
Tuttavia, questa architettura può avere senso nei seguenti casi :
per siti pubblici molto voluminosi,
per un primo livello di filtraggio ampio (geo-IP, reputazione, DDoS L7 semplice, geo-blocking).
È invece una cattiva idea :
quando tutta la logica di business è dietro un'API distinta, esposta su un altro dominio / endpoint,
quando regole molto precise (OWASP, verifiche a livello del payload di una richiesta) devono essere applicate direttamente a livello CDN.
Opzione 2 : WAF a livello del load balancer
Un'altra possibilità, più comune : agganciare il WAF a livello del load balancer, appena prima dell'origin applicativo :
In questo caso, si mantiene la piena efficacia del WAF, pur lasciando al CDN il suo ruolo naturale : continua a garantire la cache degli asset statici, la minificazione del bundle JS e le altre trasformazioni in periferia.
Il gateway di filtraggio è posizionato il più vicino possibile al server che si trova dietro il WAF, lì dove passano :
le richieste autenticate,
le mutazioni di dati,
i percorsi critici (login, pagamenti, amministrazione).
Questo posizionamento porta due benefici maggiori :
Il costo rimane concentrato sull'analisi del traffico realmente applicativo, poiché solo le richieste che raggiungono l'origin passano attraverso il WAF piuttosto che l'intero flusso CDN.
Le regole possono essere adattate finemente per listener o per percorso, il che consente di applicare politiche specifiche alle API interne, ai percorsi sensibili o alle interfacce back-office senza disturbare il resto del sito.
Opzione 3: WAF a livello dell'API Gateway
Infine, nelle architetture molto API / microservizi, il WAF è spesso integrato direttamente sulla gateway:
Questa organizzazione ha pieno senso quando:
l'essenziale del traffico è JSON / REST / SOAP / gRPC,
l'obiettivo è centralizzare i controlli sui percorsi API (metodi autorizzati, DTO, quote, ecc.).
La protezione diventa allora una combinazione:
di regole WAF, che filtrano e bloccano le richieste malevole (iniezioni, XSS, bot, ecc.) a livello del traffico HTTP(S)
di politiche API, che inquadrano l'uso funzionale degli endpoint (quote, rate limiting, validazione di schemi, trasformazione di payload, gestione di errori)
di controllo d'accesso, che garantisce che solo le identità autorizzate possano chiamare le API sensibili (autenticazione, autorizzazione fine, scopes, ruoli)
Eliminare i percorsi di bypass
Una protezione HTTP non serve a nulla se l'attaccante può raggiungere direttamente il server protetto dal WAF.
Per evitare che ciò sia possibile ci sono diverse soluzioni:
L'origin è in una rete privata (subnet non instradabile da Internet),
Solo il CDN / WAF può accedervi:
tramite CIDR di IP sorgente ristrette,
o tramite meccanismi di origine privata (PrivateLink, VPC endpoint, ecc.),
I firewall / security groups sono configurati per rigettare ogni altro traffico.
Per evitare ciò, una pratica comune su AWS consiste nel:
ALB in subnet pubblica ma:
Security Group che autorizza unicamente gli IP sorgente di CloudFront,
Eventualmente un IP fisso di bastion d'admin
Origin tipo EC2/ECS/Fargate in subnet privata, accessibile unicamente dall'ALB.
È anche possibile aggiungere un header “secret” tra il CDN e l'origin con un shared secret come valore, e rifiutare ogni richiesta che non lo contiene; è utile per limitare gli scenari di host header poisoning (quando un attaccante forgia l'header Host per mirare a un'altra applicazione dietro il reverse proxy, impedire al cache di funzionare correttamente, …), in compenso, ciò rende più complessa la configurazione.
Quanto costa un WAF ?
Un deployment tramite un cloud provider (AWS, GCP, …) implica una fatturazione a richiesta (con una tariffa decrescente in funzione del volume di richieste), mentre un deployment on-premise si basa piuttosto su una licenza a costo fisso e un investimento iniziale più importante.
In entrambi i casi, bisogna ragionare in TCO (Total Cost of Ownership), integrando la banda passante, la manutenzione, la governance e i costi nascosti di una cattiva configurazione (come i falsi positivi, la latenza o il sovraccarico dei log).
WAF Cloud
Le offerte cloud-native (AWS WAF, Azure Front Door, Google Cloud Armor, ecc.) si basano su modelli di fatturazione a richiesta. Si paga generalmente in base a:
il numero di richieste elaborate (fatturazione per scaglioni di milioni di richieste mensili),
il volume di regole attive o di moduli avanzati (bot management, IP reputation, rate limiting, ecc.),
il traffico in uscita (banda passante) e a volte il numero di distribuzioni (o domini protetti).
Queste soluzioni presentano il vantaggio di una manutenzione minima e di un'integrazione diretta ai servizi del cloud provider, ma il loro costo può crescere rapidamente se il traffico è importante o se le regole sono mal ottimizzate. Sono particolarmente adatte alle architetture elastiche dove il carico varia fortemente.
WAF on-premise
Le soluzioni on-premise si basano piuttosto su un modello di licenza fisso, spesso indicizzato su:
il throughput massimo autorizzato,
il numero di istanze o di nodi,
a volte moduli aggiuntivi (analytics, monitoring delle risorse, ecc.).
Implicano un investimento iniziale più elevato ma permettono un controllo completo del traffico, dei log e della personalizzazione delle regole. D'altra parte, richiedono più risorse umane per l'esercizio e gli aggiornamenti di sicurezza.
ModSecurity rimane l'opzione open source di riferimento, integrabile con NGINX o Apache, e serve spesso da base per un deployment WAF on-premise.
L'ottimizzazione di un WAF si inserisce in un approccio di miglioramento continuo. Non si tratta solo di installare un prodotto, ma di costruire una strategia di difesa.
Fase di apprendimento
Si raccomanda di iniziare sistematicamente in modalità osservazione ("count" su AWS, "log only" altrove). L'obiettivo non è ancora bloccare, ma tracciare tutte le richieste sospette e qualificarne la natura.
Si esportano i log verso una soluzione di Security Information and Event Management (SIEM) o un data lake, si etichettano i pattern ricorrenti (scansioni automatizzate, strumenti di audit interno, tentativi reali di exploitation) e si costruiscono delle baselines: volume per endpoint, ripartizione dei metodi, header usuali. Questa fotografia serve da riferimento per le fasi seguenti.
Rafforzamento progressivo
Una volta conosciuta la normalità, si attivano politiche positive sui percorsi critici (autenticazione, pagamenti, amministrazione). Concretamente, si descrivono gli "input contracts" autorizzati: metodi HTTP ammessi, schemi JSON attesi, set di headers tollerati, intervalli di IP conosciuti o impronte di app client.
Tutto ciò che esce da questo perimetro viene bloccato o sfidato. Si procede API per API per limitare i falsi positivi, si alimenta un piano d'intervento che precisa quali azioni intraprendere in caso di allerta (disattivazione temporanea, creazione di una regola d'eccezione, escalation verso il team Product).
Automazione e governance
Il WAF diventa duraturo quando è gestito come codice. Le regole sono descritte in un repository IaC (come Terraform), le modifiche passano attraverso la revisione del codice, e test automatizzati (es. terraform plan, suite di richieste curl o k6 riproducendo i casi critici) validano che una modifica non interrompa un percorso legittimo.
Versioniamo anche i dizionari di firme interne, tagghiamo ogni regola con un ticket o un incidente per conservare la tracciabilità, e documentiamo le dipendenze (API interessate, team proprietari) per poterli notificare in caso di modifica.
Monitoraggio dei KPI
Per seguire l'irrigidimento delle regole, questi KPI sono i più pertinenti:
Tasso di falsi positivi (obiettivo <0,1%) : confronta regole attivate e incidenti reali.
Rapporto osservato vs bloccato : misura la parte di regole ancora in rilevamento e il passaggio progressivo al blocco.
Latenza aggiunta (obiettivo <30 ms P95) : monitora il costo delle prestazioni del WAF.
Copertura funzionale : percentuale di API protette da una politica positiva.
In aggiunta, misuriamo il tempo medio di reazione per creare una regola a seguito di un incidente e il tempo medio per eliminare o allentare una regola diventata inutile, al fine di garantire che il sistema rimanga agile.
Supporto Galadrim
Presso Galadrim, gestiamo già WAF in produzione per diversi settori: e-commerce soggetto a forti variazioni di carico, fintech regolamentate, editori SaaS che espongono API critiche, attori del settore sanitario, ecc.
Il nostro team MSSP progetta le politiche positive, implementa l'IaC, monitora i KPI e interviene in caso di incidenti.
Conclusione
Un WAF non è infallibile: non può né correggere un'applicazione vulnerabile, né sostituire buone pratiche di sviluppo. D'altro canto, è uno strumento prezioso per controllare meglio il traffico e capire meglio gli incidenti. Ben configurato, aiuta a rilevare prima i comportamenti anomali, a ridurre l'impatto di un attacco e a mantenere la disponibilità dei servizi.
Il suo valore si rivela pienamente quando è abbinato a una solida igiene applicativa : una superficie di attacco ridotta, correzioni applicate rapidamente e una gestione rigorosa delle identità e degli accessi. In questo contesto, il WAF diventa un alleato della resilienza operativa, un mezzo per assorbire l'imprevedibile mantenendo il controllo della propria esposizione al rischio.
Per finire, tieni a mente questi errori da evitare:
Posizionare il WAF prima del CDN: ciò annulla i benefici della cache e aumenta la latenza.
Lasciare l'origin accessibile: l'applicazione deve essere raggiungibile solo tramite il CDN o il WAF. Qualsiasi accesso diretto può costituire una vulnerabilità.
Attivare il blocco senza un periodo di osservazione: è imperativo iniziare in modalità di rilevamento, il tempo di regolare le regole ed eliminare i falsi positivi.
Configurare manualmente: senza IaC, le deviazioni di configurazione si accumulano e la tracciabilità scompare.
