Chi gestisce un’applicazione web esposta su internet deve rispondere a una domanda pratica: quale web application firewall mettere davanti al traffico in ingresso. Le opzioni si sono ristrette a tre famiglie ben distinte. Da un lato Cloudflare WAF, il filtro edge che intercetta il traffico prima che raggiunga il server. Dall’altro AWS WAF, il motore nativo integrato in CloudFront e Application Load Balancer. E poi c’è ModSecurity, il motore open source che da oltre vent’anni protegge server Apache e Nginx, oggi affiancato dal suo erede scritto in Go, OWASP Coraza. Nel 2026 la scelta non è più solo tecnica: pesano prezzo, latenza, tasso di falsi positivi e capacità di reggere alle tecniche di bypass che i ricercatori hanno documentato negli ultimi dodici mesi. Questo confronto mette a terra numeri verificabili, non promesse di marketing.
Cos’è un Web Application Firewall e perché conta ancora nel 2026
Un web application firewall filtra il traffico HTTP/HTTPS diretto a un’applicazione, cercando pattern tipici di attacco come SQL injection, cross-site scripting o tentativi di path traversal, e blocca le richieste sospette prima che arrivino al codice applicativo. A differenza di un firewall di rete tradizionale, lavora al livello 7, quello applicativo, dove transitano payload JSON, form multipart e header manipolati.
Il mercato globale dei WAF vale 9,37 miliardi di dollari nel 2025 e sale a 11,01 miliardi nel 2026, con una crescita annua stimata al 14,9% fino al 2031, secondo Mordor Intelligence. Numeri simili arrivano da Precedence Research, che colloca il mercato a 12,77 miliardi di dollari nel 2026. Dietro questi numeri c’è una spinta precisa: l’OWASP Top 10 2025 ha introdotto categorie come la gestione impropria delle condizioni eccezionali, e i team di sicurezza cercano uno strato di protezione che non richieda una riscrittura del codice per ogni nuova minaccia.
Un WAF non va confuso con un sistema IDS/IPS di rete: quest’ultimo osserva pacchetti e connessioni, mentre il WAF legge il contenuto della richiesta applicativa, compresi corpo JSON, cookie e parametri della query string. Questa differenza spiega perché un’azienda può avere già un firewall perimetrale solido e restare comunque esposta a un attacco di SQL injection: il traffico appare legittimo a livello di rete, ma nasconde un payload malevolo nel corpo della richiesta HTTP che solo un’ispezione a livello applicativo riesce a intercettare. Le tre famiglie di prodotto analizzate in questo articolo, edge, cloud-native e self-hosted, rispondono tutte allo stesso problema con architetture radicalmente diverse, ed è proprio questa differenza architetturale a determinare costi, latenza e capacità di adattarsi a un attacco nuovo.
Forrester ha pubblicato la sua Wave sulle soluzioni WAF nel primo trimestre 2025, riconoscendo Cloudflare come leader di categoria. Il dato interessante è che la domanda di WAAP (WAF più protezione API) è ripartita con forza dopo un 2022-2023 di relativa stagnazione, spinta da rilevamento basato su modelli e requisiti normativi più stringenti in Europa. Per chi gestisce infrastrutture cloud, il tema si intreccia con la sicurezza della postura cloud, perché un WAF mal configurato è spesso solo il sintomo di un problema più ampio di governance.
Cloudflare WAF: come funziona la protezione a livello edge
Cloudflare WAF si posiziona davanti al server d’origine, sfruttando la rete di data center distribuiti dell’azienda. Il traffico attraversa il punto di presenza più vicino all’utente, viene ispezionato lì e solo le richieste pulite proseguono verso il backend. Questo modello riduce il carico sul server d’origine e, in teoria, aggiunge pochi millisecondi di latenza perché l’elaborazione avviene vicino al client.
Il prodotto si basa su regole gestite aggiornate centralmente, un motore di rilevamento che assegna un punteggio di minaccia a ogni richiesta e la possibilità di scrivere espressioni personalizzate con la sintassi Cloudflare Rules Language. Il piano gratuito include cinque regole WAF personalizzate, il piano Pro ne offre venti, il Business sale a cento. Chi ha bisogno di regole illimitate e SLA dedicati deve passare a Enterprise, con prezzo su preventivo.
SecureIQLab ha testato Cloudflare nel suo report Cloud WAAP CyberRisk Validation 2025, assegnando un punteggio di efficacia di sicurezza del 62,92% su nove categorie in stile OWASP Top 10, e un punteggio di evitamento dei falsi positivi del 97,76%. Questo significa che Cloudflare tende a bloccare con parsimonia, privilegiando la continuità operativa rispetto al blocco aggressivo, una scelta di design che riduce le interruzioni per gli utenti legittimi ma lascia più margine di manovra agli attaccanti più sofisticati.
AWS WAF: integrazione nativa con CloudFront e Application Load Balancer
AWS WAF nasce per chi vive già dentro l’ecosistema Amazon. Si collega direttamente a CloudFront, Application Load Balancer, API Gateway e AppSync senza bisogno di cambiare il DNS o instradare il traffico verso un provider terzo. Ogni web ACL (Access Control List) raccoglie un insieme di regole, gestite o personalizzate, che vengono valutate in ordine di priorità.
Il modello di prezzo è diverso da quello di Cloudflare: non ci sono piani a fascia fissa ma un costo a consumo. Amazon fattura 1 dollaro al mese, proratato su base oraria, per ogni gruppo di regole o regola gestita aggiunta a un web ACL, più 0,20 dollari per milione di richieste ogni 500 unità di capacità richieste (WCU) utilizzate oltre l’allocazione predefinita di 1.500 WCU, secondo la pagina ufficiale dei prezzi AWS WAF. Questo modello premia i team che sanno dimensionare con precisione il numero di regole attive, ma può diventare imprevedibile per chi ha picchi di traffico stagionali.
La forza di AWS WAF sta nell’integrazione con il resto della piattaforma: AWS Shield per la mitigazione DDoS, AWS Firewall Manager per applicare policy centralizzate su decine di account, e Bot Control per il rilevamento di traffico automatizzato. Per un’azienda che ha già costruito la propria architettura su CloudFront e ALB, aggiungere AWS WAF significa una riga di configurazione in più in Terraform, non un nuovo fornitore da gestire.
Va detto che alcuni componenti restano a listino separato: Bot Control e Fraud Control si pagano a parte in base al volume di richieste analizzate, e la protezione DDoS avanzata tramite Shield Advanced richiede un abbonamento annuale con un canone che parte da diverse migliaia di dollari, pensato per aziende con esigenze di mitigazione volumetrica importanti. Per un team piccolo che vuole solo bloccare SQL injection e XSS di base, il costo reale finisce per essere più vicino a poche decine di dollari al mese, ma chi aggiunge livelli di protezione avanzati vede la fattura salire in fretta rispetto a un piano Cloudflare a prezzo fisso.
ModSecurity e OWASP Coraza: la via open source
ModSecurity è il motore open source più citato nella storia dei WAF, nato per Apache e poi esteso a Nginx e IIS. Nel 2024 la sua storia si è biforcata: Trustwave ha chiuso il supporto commerciale, con fine vendita dal 1° agosto 2021 e fine vita per il supporto e le regole commerciali dal 1° luglio 2024, come confermato dal blog ufficiale di LevelBlue (ex Trustwave SpiderLabs). Il connettore NGINX ModSecurity WAF è passato a fine vita il 31 marzo 2024, secondo quanto dichiarato da F5 NGINX. Il motore open source, però, continua a esistere sotto manutenzione della comunità: non è morto, ha solo perso lo sponsor commerciale.
Proprio da questa transizione è cresciuto OWASP Coraza, un motore compatibile con la sintassi delle regole ModSecurity ma riscritto da zero in Go. L’ultima versione stabile è la 3.7.0, rilasciata il 6 aprile 2026, e il progetto ha raccolto circa 3.600-3.800 stelle su GitHub. A differenza di ModSecurity, Coraza non ha un modulo nativo per Nginx: per usarlo servono un reverse proxy Caddy con il plugin coraza-caddy, HAProxy con coraza-spoa, oppure un’integrazione Envoy tramite modulo dinamico Go, filtro HTTP o proxy-wasm, quest’ultima pensata apposta per ambienti Kubernetes e service mesh.
Entrambi i motori si appoggiano all’OWASP Core Rule Set (CRS), il set di regole di rilevamento mantenuto dalla community OWASP. La versione più recente è la 4.29.0, pubblicata il 17 agosto 2026 secondo il changelog su coreruleset.org. Il progetto mantiene anche due rami a supporto lungo, la 4.25.1 e la 3.3.10, annunciati il 2 luglio 2026 per chi preferisce aggiornamenti meno frequenti ma testati più a lungo.
Chi configura CRS deve familiarizzare con il concetto di Paranoia Level, un valore da 1 a 4 che regola quanto le regole siano aggressive. Al livello 1 si blocca solo il traffico palesemente malevolo, con pochissimi falsi positivi ma anche minore copertura. Al livello 4 si intercettano varianti di attacco molto più sottili, al prezzo di un numero di blocchi indesiderati che sale in modo marcato su applicazioni con form complessi o upload di file. La maggior parte delle guide operative consiglia di partire dal livello 1 in produzione e di alzarlo gradualmente solo dopo aver verificato l’impatto sul traffico reale per almeno due settimane.
Tabella comparativa: le specifiche tecniche a confronto
La tabella seguente mette fianco a fianco le caratteristiche tecniche principali dei tre approcci, basandosi sulle pagine ufficiali di prodotto e sulla documentazione dei rispettivi progetti.
| Caratteristica | Cloudflare WAF | AWS WAF | ModSecurity / Coraza |
|---|---|---|---|
| Modello di implementazione | Edge (rete globale Cloudflare) | Cloud (CloudFront, ALB, API Gateway) | Self-hosted (server o container) |
| Motore di rilevamento | Proprietario, basato su punteggio minaccia | Regole gestite AWS + regole custom | OWASP Core Rule Set 4.29.0 |
| Linguaggio del motore | Proprietario (non pubblico) | Proprietario (non pubblico) | C (ModSecurity) / Go (Coraza) |
| Licenza | Servizio commerciale | Servizio commerciale a consumo | Open source (AGPL / Apache 2.0) |
| Integrazione Nginx | Non richiesta (proxy esterno) | Non richiesta (proxy esterno) | Nativa per ModSecurity, assente per Coraza |
| Integrazione Kubernetes/Envoy | Via Cloudflare Tunnel | Via ALB Ingress Controller | Coraza-proxy-wasm su Envoy |
| Protezione DDoS inclusa | Sì, integrata di default | Tramite AWS Shield (separato) | No, va aggiunta a parte |
| Bot management | Incluso da piano Business | AWS WAF Bot Control (a consumo) | Non incluso nativamente |
| Regole personalizzate | 5 (Free) – 100 (Business) – illimitate (Enterprise) | Illimitate, a costo per gruppo | Illimitate, gestite dall’utente |
| Aggiornamento regole gestite | Automatico, centralizzato | Automatico per managed rule group | Manuale, richiede pull da coreruleset.org |
| Supporto commerciale | Incluso da Pro in su | AWS Support (piano separato) | Nessuno strutturato dal 2024 |
| Controllo del codice sorgente | Nessuno | Nessuno | Completo |
Prezzi 2026: quanto costa proteggere un’applicazione
Il costo di un WAF cambia radicalmente in base al modello scelto. Cloudflare lavora a fasce fisse mensili, AWS WAF fattura a consumo in base al numero di regole attive e al volume di richieste, mentre ModSecurity e Coraza sono gratuiti ma spostano il costo sull’infrastruttura e sul tempo ingegneristico necessario per gestirli.
| Soluzione | Piano | Prezzo | Regole custom incluse |
|---|---|---|---|
| Cloudflare WAF | Free | 0 $/mese | 5 regole |
| Cloudflare WAF | Pro | 20 $/mese (annuale) o 25 $/mese | 20 regole |
| Cloudflare WAF | Business | 200 $/mese (annuale) o 250 $/mese | 100 regole |
| Cloudflare WAF | Enterprise | Su preventivo, fatturazione annuale | Illimitate |
| AWS WAF | A consumo | 1 $/mese per gruppo di regole + 0,20 $ per milione di richieste ogni 500 WCU oltre l’allocazione base | Illimitate (a costo) |
| ModSecurity | Open source | 0 $ (licenza), costo hosting a parte | Illimitate |
| OWASP Coraza | Open source | 0 $ (licenza), costo hosting a parte | Illimitate |
Su un’applicazione con traffico medio, il conto cambia molto in base al numero di regole gestite attivate su AWS WAF: attivare cinque gruppi di regole gestite costa circa 5 dollari al mese solo di base, prima ancora di contare il volume di richieste. Cloudflare, al contrario, offre prevedibilità: si paga la stessa cifra indipendentemente da quante richieste arrivano, un vantaggio per chi ha budget fissi ma uno svantaggio per chi ha traffico molto basso e finirebbe per pagare più del necessario rispetto al modello a consumo di AWS.
ModSecurity e Coraza restano gratuiti a livello di licenza, ma chi li sceglie deve mettere in conto ore di configurazione, tuning delle regole per ridurre i falsi positivi e, se serve alta disponibilità, un’infrastruttura ridondante che Cloudflare e AWS offrono già inclusa nel prezzo del servizio.
Benchmark: latenza, throughput e falsi positivi a confronto
Non esiste, ad oggi, un singolo laboratorio indipendente che abbia testato tutti e quattro i motori (Cloudflare, AWS WAF, ModSecurity, Coraza) con la stessa metodologia. I dati disponibili arrivano da fonti diverse, ciascuna con il proprio ambiente di test, e vanno letti come indicazioni di tendenza più che come classifiche assolute.
| Fonte del test | ModSecurity | Coraza | Metrica |
|---|---|---|---|
| Community benchmark su traffico sintetico (2025) | 175 falsi negativi, 7.381 falsi positivi, accuratezza 77,56% | 171 falsi negativi, 5.182 falsi positivi, accuratezza 84,10% | Rilevamento e falsi positivi |
| WAFWiki, test locale Docker (2026) | Latenza mediana 3,96 ms, p95 5,52 ms | Latenza mediana 3,57 ms, p95 4,90 ms | Latenza per richiesta |
| Benchmark self-hosted con CRS paranoia level 1 (2026) | 12.400 richieste/sec, p99 8,2 ms, 120 MB RAM | 16.800 richieste/sec, p99 4,1 ms, 45 MB RAM | Throughput e memoria |
| Confronto WAF self-hosted su GitHub (2025) | Rilevamento 69,74%, falsi positivi 17,58% | Rilevamento circa 65%, falsi positivi circa 10% | Efficacia con regole di default |
Il pattern che emerge da queste fonti indipendenti è coerente: Coraza tende a essere più veloce di ModSecurity a parità di ruleset, con un guadagno di throughput stimato tra il 20% e il 40% secondo il benchmark self-hosted pubblicato nel 2026, e con un consumo di memoria molto più basso grazie al runtime Go. Sul fronte dei falsi positivi, entrambi i motori open source restano lontani dalla precisione delle soluzioni commerciali quando si usano le regole CRS di default, come conferma anche il confronto pubblicato su dev.to: servono ore di tuning per portare il tasso di blocchi indesiderati a livelli accettabili in produzione.
Per Cloudflare, il riferimento più solido resta il report SecureIQLab già citato: punteggio di efficacia di sicurezza del 62,92% e di evitamento falsi positivi del 97,76%. Per AWS WAF, invece, non è emerso nessun test indipendente 2025-2026 che pubblichi numeri equivalenti di tasso di falsi positivi o throughput: le uniche descrizioni disponibili restano qualitative, il che rende difficile un confronto diretto e onesto sulla carta.
Vale la pena spiegare perché questo divario di dati esiste. I laboratori indipendenti come SecureIQLab testano soprattutto le piattaforme edge/cloud vendute come servizio completo (WAAP), perché sono quelle acquistate direttamente dai team di sicurezza aziendali e quindi oggetto di comparazione commerciale. I motori open source, al contrario, vengono benchmarkati soprattutto da sviluppatori indipendenti o da piccoli team che pubblicano i risultati su blog personali e piattaforme come dev.to, con metodologie meno formali ma dati grezzi più trasparenti. Nessuno dei due mondi, però, ha ancora prodotto un test che metta tutti e quattro i motori sullo stesso banco di prova con lo stesso traffico sintetico, e questo resta il limite più grande per chi vuole decidere solo sulla base dei numeri.
Bypass WAF: le tecniche di evasione che nessuna configurazione ferma del tutto
Nessun WAF, per quanto ben configurato, è impenetrabile. Nel gennaio 2026 Cloudflare ha corretto un bug che permetteva di aggirare le regole WAF e raggiungere direttamente il server d’origine, come riportato da The Register. La falla riguardava la gestione della catena di certificati durante l’handshake TLS: un certificato alterato poteva ingannare il componente di verifica e far passare traffico che avrebbe dovuto essere bloccato.
Sul fronte AWS, SentinelOne ha documentato la CVE-2026-13762, una vulnerabilità di bypass in distribuzioni CloudFront con AWS WAF attivo: frammentando le richieste HTTP/2 su più frame, un attaccante può far terminare l’ispezione del WAF prima che il payload malevolo venga analizzato per intero, una tecnica classificata come request smuggling.
Un filone di ricerca accademico del 2025, noto come WAFFLED, ha mostrato come le discrepanze di parsing tra WAF e backend possano generare bypass sistematici: inviando lo stesso payload con content-type diversi (JSON, multipart, XML) gli autori dello studio hanno ottenuto 1.207 bypass distinti testando cinque WAF differenti, tra cui AWS, Cloudflare e ModSecurity. A questo si aggiunge la tecnica Ghost Bits, presentata a Black Hat Asia 2026, che sfrutta un troncamento dei bit alti nei caratteri Unicode durante la decodifica in ambienti Java, capace secondo i ricercatori di NSFOCUS di rendere inefficaci le difese WAF e IDS più diffuse negli stack colpiti.
La lezione pratica per chi amministra un WAF, di qualunque marca, è che le regole vanno trattate come un livello di difesa in profondità, non come una soluzione definitiva. Vale la pena integrare il WAF con controlli lato applicazione, seguendo le raccomandazioni della guida alla remediation OWASP Top 10, invece di considerarlo l’unico scudo.
Diversi articoli tecnici pubblicati nel 2025 raccolgono un catalogo più ampio di tecniche di evasione ancora efficaci: offuscamento del payload tramite doppia codifica URL o Unicode, parameter pollution che duplica lo stesso parametro con valori diversi, uso di metodi HTTP alternativi come PUT o TRACE per instradare la richiesta verso percorsi meno controllati, e attacchi in stile slow-loris che spezzano il payload byte per byte per eludere le euristiche di ispezione. Alcuni ricercatori hanno anche sperimentato framework che usano modelli linguistici e reinforcement learning per generare automaticamente payload capaci di eludere un WAF, un segnale che la corsa tra attacco e difesa a questo livello si sta spostando sempre più verso l’automazione su entrambi i fronti.
CVE e vulnerabilità: cosa è successo a ModSecurity nel 2025-2026
Chi sceglie un motore open source deve seguire da vicino il ciclo delle vulnerabilità, perché non c’è un vendor che invia patch automatiche. Nel 2025 sono state pubblicate quattro CVE che riguardano ModSecurity e libmodsecurity3: la CVE-2025-47947, un denial of service legato alla trasformazione sanitiseMatchedBytes su richieste con Content-Type JSON, corretta nella versione 2.9.9. La CVE-2025-48866, un altro DoS attivabile tramite sanitiseArg, risolta nella 2.9.10. La CVE-2025-54571, più seria, permette di sovrascrivere l’header Content-Type della risposta HTTP, aprendo la porta a XSS o divulgazione di codice sorgente, corretta nella versione 2.9.12. E la CVE-2025-27110, un bug nella decodifica delle entità HTML in libmodsecurity3 3.0.13, risolto nella 3.0.14.
Il 2026 ha portato problemi più delicati, perché alcuni riguardano direttamente il bypass delle regole. La CVE-2026-30923 provoca un crash tramite la trasformazione t:hexDecode su un parametro con un singolo carattere, corretta nella versione 3.0.15. La CVE-2026-42268 genera un’eccezione non gestita quando si usano gli operatori di verifica come verifySSN o verifyCPF. Più preoccupanti sono la CVE-2026-52747, che riguarda il parser multipart/form-data: rimuove silenziosamente gli a-capo incorporati nei campi del form prima di esportarli, mentre il backend li conserva, creando una discrepanza sfruttabile per aggirare le regole basate su quei caratteri. E la CVE-2026-52761, un bug nella trasformazione t:utf8toUnicode su architettura i386 che porta a un bypass delle regole che la usano, corretto nella versione 3.0.16. Il blog ufficiale di ModSecurity ha pubblicato i dettagli di queste ultime due falle il 29 giugno 2026.
Su Coraza, la ricerca raccolta per questo articolo non ha individuato CVE pubbliche registrate nel 2025-2026. Questo non significa che il progetto sia privo di rischi, significa solo che le principali basi dati pubbliche non riportano voci specifiche per Coraza in quel periodo: un dato che va letto anche alla luce della base di codice più piccola e più recente rispetto a ModSecurity, che ha vent’anni di storia e una superficie di attacco proporzionalmente più ampia.
5 casi d’uso reali: chi sceglie cosa e perché
La scelta del WAF giusto dipende quasi sempre dal contesto infrastrutturale già esistente più che da un confronto astratto di feature. Chi parte da zero e vuole prima capire come si comporta un motore basato su regole prima di scegliere il provider può seguire la nostra guida pratica su come integrare ModSecurity con un’applicazione Node.js, un buon modo per toccare con mano concetti come paranoia level e tuning delle regole prima di impegnarsi su un budget annuale. Ecco cinque scenari tipici osservati tra le realtà europee.
- E-commerce di piccola e media impresa italiana su Shopify o WooCommerce: il piano Cloudflare Pro a 20 dollari al mese offre protezione DDoS, WAF gestito e certificati SSL in un unico abbonamento, senza bisogno di un team infrastrutturale dedicato.
- Startup SaaS B2B costruita su AWS con CloudFront e Application Load Balancer: attivare AWS WAF significa restare dentro un’unica fattura, un’unica console IAM e gli stessi log su CloudWatch già usati per il resto dello stack.
- Banca o fintech europea con obblighi di audit stringenti: la scelta ricade spesso su ModSecurity self-hosted, perché il team di sicurezza vuole poter leggere e modificare ogni singola regola e dimostrare tracciabilità completa agli ispettori.
- Media company con traffico globale e picchi imprevedibili durante eventi live: il piano Cloudflare Business o Enterprise, con bot management e mitigazione DDoS incluse, evita di dover dimensionare manualmente la capacità in anticipo.
- Team DevOps con architettura Kubernetes-native: Coraza integrato via proxy-wasm su Envoy si inserisce nel service mesh esistente senza aggiungere un ulteriore livello di rete gestito da terzi, mantenendo tutto dentro il cluster.
Un sesto scenario, sempre più comune dopo l’entrata in vigore della NIS2 in Italia, riguarda le pubbliche amministrazioni locali: molte scelgono ModSecurity o Coraza proprio per mantenere i dati e le regole di filtraggio su infrastruttura sotto controllo diretto, evitando di dipendere da un fornitore extra-UE per una funzione di sicurezza critica.
Guida alla migrazione tra WAF
Cambiare WAF senza lasciare finestre di esposizione richiede un percorso in parallelo, mai una sostituzione secca. Questi sono i passaggi che riducono il rischio di downtime o di bucature temporanee.
- Esportare tutte le regole personalizzate e i log degli ultimi 90 giorni dal WAF attuale, per avere una base di riferimento su cosa viene bloccato oggi.
- Distribuire il nuovo WAF in modalità “solo log” (detection-only), senza blocco attivo, per almeno due settimane.
- Confrontare i blocchi che il vecchio sistema avrebbe generato con quelli segnalati dal nuovo, per individuare differenze di comportamento prima del taglio.
- Ricreare le regole personalizzate una per una, testandole singolarmente invece di importarle in blocco.
- Se si migra verso ModSecurity o Coraza, impostare il Paranoia Level del Core Rule Set al livello 1 e alzarlo gradualmente, monitorando i falsi positivi a ogni passaggio.
- Attivare il nuovo WAF in blocco attivo solo su un sottoinsieme di traffico (ad esempio il 10%), usando un bilanciatore o un header di routing.
- Estendere la copertura in modo incrementale, mantenendo il vecchio WAF come rete di sicurezza per due settimane aggiuntive prima dello spegnimento definitivo.
- Documentare ogni regola personalizzata migrata, con la motivazione originale, per evitare che diventi un debito tecnico invisibile.
Chi migra da AWS WAF verso Cloudflare deve anche pianificare la propagazione DNS e verificare che le IP di origine vengano nascoste correttamente, altrimenti un attaccante può bypassare il nuovo WAF collegandosi direttamente al server tramite l’indirizzo IP esposto in precedenza. Un errore di configurazione comune, e facilmente evitabile con una regola firewall a livello di rete che accetta connessioni solo dai range IP del provider WAF scelto.
Vale anche la pena preparare un piano di rollback scritto prima di iniziare, non durante un incidente. Deve indicare chi ha l’autorità di decidere il ritorno al sistema precedente, quale soglia di falsi positivi o di richieste bloccate erroneamente giustifica l’interruzione della migrazione, e quale canale di comunicazione avvisa il resto del team in tempo reale. Le migrazioni che falliscono peggio sono quasi sempre quelle senza un criterio oggettivo di stop, dove la decisione di tornare indietro viene presa troppo tardi, dopo che gli utenti hanno già segnalato problemi.
Pro e contro di ciascuna soluzione
Cloudflare WAF
Tra i punti di forza: prezzo prevedibile a fascia fissa, protezione DDoS inclusa di default, rete edge globale che riduce la latenza percepita e un alto punteggio di evitamento falsi positivi secondo SecureIQLab. Tra i limiti: il motore di rilevamento è proprietario e non ispezionabile, il piano gratuito limita fortemente le regole personalizzate, e affidarsi a un unico provider per WAF, DNS e CDN concentra il rischio operativo su un solo fornitore.
AWS WAF
Punti di forza: integrazione nativa con CloudFront, ALB e il resto dello stack AWS, log strutturati già dentro CloudWatch e Firewall Manager per policy centralizzate multi-account. Limiti: prezzo a consumo che può diventare difficile da prevedere con molti gruppi di regole attivi, assenza di dati indipendenti 2025-2026 su falsi positivi e throughput, e un vincolo di fatto all’ecosistema Amazon che rende la migrazione verso altri cloud più complessa in futuro.
ModSecurity e OWASP Coraza
Punti di forza: costo di licenza pari a zero, controllo completo del codice e delle regole, nessun vincolo di fornitore e possibilità di ispezionare ogni riga di configurazione per audit di conformità. Limiti: tasso di falsi positivi elevato con le regole CRS di default (tra il 10% e il 17,58% secondo i benchmark citati), nessun supporto commerciale strutturato dal 2024 per ModSecurity, assenza di un modulo nativo Nginx per Coraza, e la responsabilità di applicare patch di sicurezza ricade interamente sul team interno.
Conformità GDPR e NIS2: cosa conta per le aziende europee
Per le aziende italiane ed europee, la scelta del WAF non è solo una questione tecnica ma anche di conformità normativa. Un WAF gestito da un fornitore extra-UE comporta il trasferimento di metadati di traffico, indirizzi IP e talvolta payload delle richieste verso data center fuori dal territorio europeo, un punto che va valutato insieme al proprio responsabile della protezione dei dati prima di firmare qualunque contratto.
Con l’obbligo NIS2 esteso a migliaia di soggetti essenziali e importanti in Italia, la capacità di dimostrare come vengono trattati i log del WAF, per quanto tempo vengono conservati e chi vi può accedere, è diventata parte della documentazione richiesta durante le ispezioni. Un WAF open source self-hosted semplifica questa dimostrazione perché i dati restano fisicamente sotto il controllo dell’organizzazione, mentre un WAF cloud richiede di verificare accordi sul trattamento dei dati e, quando possibile, opzioni di data residency europea, oggi offerte sia da Cloudflare sia da AWS per i clienti enterprise. Chi ha già affrontato un percorso simile per il livello di API gateway può ritrovare logiche comparabili nel nostro confronto tra Kong e KrakenD su conformità GDPR e Cloud Act.
Il Cyber Resilience Act, con le sue scadenze progressive per i prodotti con elementi digitali venduti nell’Unione Europea, aggiunge un ulteriore livello di attenzione: dimostrare che un componente critico come il WAF riceve patch di sicurezza in tempi ragionevoli diventa parte degli obblighi di due diligence verso clienti e fornitori. Per chi si affida a ModSecurity, questo significa monitorare attivamente il blog ufficiale del progetto e i bollettini CVE, perché non arriverà nessuna notifica automatica come accade con un servizio gestito.
Verdetto finale: quale WAF scegliere nel 2026
Non esiste un vincitore assoluto, ma i dati raccolti permettono di tracciare confini netti tra i profili di utenti a cui ogni soluzione si adatta meglio. Cloudflare WAF resta la scelta più rapida da attivare per chi vuole protezione DDoS, edge e WAF in un unico abbonamento a prezzo fisso, con un track record solido su bassi falsi positivi secondo test indipendenti. AWS WAF vince quando l’infrastruttura è già interamente su Amazon e il valore dell’integrazione nativa supera il costo di gestione di un modello a consumo meno prevedibile.
ModSecurity e Coraza restano l’opzione giusta per chi ha vincoli di conformità stringenti, un team di sicurezza capace di dedicare tempo al tuning delle regole, e la volontà di non dipendere da un fornitore terzo per una funzione critica. Tra i due, Coraza è la scelta più moderna per chi lavora già con Envoy o Kubernetes, con throughput superiore del 20-40% rispetto a ModSecurity nei benchmark disponibili, mentre ModSecurity resta più semplice da integrare per chi ha già uno stack Nginx tradizionale grazie al connettore nativo.
La raccomandazione pratica, in ogni caso, è di non considerare il WAF scelto come punto finale. Va combinato con audit periodici, scansioni di vulnerabilità con strumenti come Nessus o OpenVAS, e con controlli applicativi coerenti con le raccomandazioni OWASP, l’unico modo per ridurre davvero la superficie che le tecniche di bypass documentate nel 2025-2026 continuano a sfruttare.
Domande frequenti
Qual è la differenza principale tra Cloudflare WAF e AWS WAF?
Cloudflare WAF opera a livello edge su una rete globale indipendente dal cloud provider, con prezzo a fascia fissa. AWS WAF si integra nativamente con CloudFront e Application Load Balancer e fattura a consumo in base al numero di regole attive e al volume di richieste.
ModSecurity è ancora sicuro da usare nel 2026?
Il motore open source continua a ricevere patch di sicurezza dalla comunità, come dimostrano le versioni 3.0.15 e 3.0.16 rilasciate nel 2026 per correggere bug di bypass delle regole. È finito solo il supporto commerciale di Trustwave dal luglio 2024, non lo sviluppo del progetto in sé.
Coraza può sostituire ModSecurity senza modificare le regole esistenti?
In gran parte sì, perché Coraza mantiene compatibilità con la sintassi delle regole ModSecurity e con l’OWASP Core Rule Set. Va comunque previsto un test in modalità solo log prima del passaggio in produzione, perché piccole differenze di implementazione possono cambiare il comportamento di alcune regole.
Quanto costa davvero AWS WAF su un traffico medio?
Il costo base parte da 1 dollaro al mese per ogni gruppo di regole attivo, più 0,20 dollari per milione di richieste ogni 500 WCU oltre l’allocazione gratuita di 1.500 WCU. Con cinque gruppi di regole gestite attivi, il costo fisso mensile si aggira sui 5 dollari, prima di contare il traffico.
Un WAF open source come ModSecurity è adatto a una piccola azienda?
Solo se in azienda c’è competenza tecnica per gestire configurazione, tuning e patch di sicurezza. Senza queste risorse, un tasso di falsi positivi tra il 10% e il 17,58% nei test di riferimento rischia di bloccare traffico legittimo o, se allentato troppo, di lasciare passare attacchi reali.
Un WAF basta da solo a bloccare tutti gli attacchi web?
No. Le tecniche di bypass documentate nel 2025-2026, dalle discrepanze di parsing dello studio WAFFLED alla vulnerabilità CVE-2026-13762 su AWS CloudFront, dimostrano che un WAF va trattato come un livello di difesa tra molti, non come soluzione unica.
Cloudflare Free è sufficiente per proteggere un sito in produzione?
Per un sito con traffico basso e rischio contenuto può bastare, grazie alle cinque regole personalizzate incluse e alla protezione DDoS di base. Chi gestisce dati sensibili o transazioni economiche dovrebbe valutare almeno il piano Pro per avere più margine di personalizzazione delle regole.
Quali certificazioni di compliance offrono i WAF cloud in Europa?
Sia Cloudflare sia AWS offrono opzioni di data residency europea per i clienti enterprise e documentazione a supporto degli audit GDPR e NIS2. Per i requisiti più stringenti, alcune organizzazioni preferiscono comunque un motore self-hosted come ModSecurity o Coraza, che mantiene i log fisicamente sotto controllo diretto.
