Hai un'app web su un VPS. Il log degli accessi mostra tentativi di login su /wp-admin, richieste con UNION SELECT nella query string e traffico costante da intervalli IP di datacenter che non hanno motivo di visitare il tuo sito. Vuoi filtrare la spazzatura evidente prima che raggiunga la tua applicazione.
È il momento in cui la maggior parte delle persone incontra il termine WAF SaaS. Per molti lettori «il WAF» e «Cloudflare» sono la stessa cosa, perché Cloudflare è ciò in cui si sono imbattuti per primo. Non sono la stessa cosa. Il WAF SaaS è una categoria: un web application firewall erogato dal cloud che ispeziona il tuo traffico HTTP sull'edge del provider prima di inoltrarlo alla tua origine. Cloudflare è un prodotto all'interno di quella categoria.
Questo articolo spiega come funziona il WAF SaaS, quanto fanno pagare i principali provider, dove fallisce nella pratica e quando far girare un WAF tuo su un VPS Linux è l'opzione migliore.
TL;DR
- Il WAF SaaS è un web application firewall erogato dal cloud. Instradi il traffico attraverso il provider oppure associ il WAF a una risorsa cloud supportata; il servizio valuta le richieste HTTP(S) prima che l'applicazione protetta le gestisca.
- I principali provider usano tre forme di pricing: livelli in abbonamento (Cloudflare e Sucuri), fatturazione a consumo (AWS WAF) e preventivi commerciali (Imperva e Fastly). I costi a consumo crescono con le richieste elaborate e le funzioni opzionali, mentre i piani in abbonamento sono in genere più prevedibili.
- Esiste una critica documentata del WAF SaaS, ed è affrontata più avanti. Punta il dito su latenza, falsi positivi, blocchi opachi e instradamento dei dati verso terze parti.
- I WAF auto-ospitati su un VPS sono un'opzione concreta. SafeLine e BunkerWeb sono i due progetti open source con slancio attuale. Girano come reverse proxy davanti alla tua applicazione.
- Nessun WAF può essere una scelta difendibile quando la sicurezza applicativa è matura, l'esposizione è controllata, il monitoraggio è solido e il rischio residuo è documentato e accettato.
Come funziona il WAF SaaS
Una richiesta verso example.com colpisce prima l'edge del provider, perché il tuo DNS punta lì. Il nodo edge termina il TLS, analizza la richiesta HTTP, la fa passare per un motore di regole e poi la inoltra alla tua origine, la blocca, la sfida (CAPTCHA, test JavaScript) o limita il rate della sorgente. Se la inoltra, la tua applicazione vede la richiesta come se arrivasse dall'IP del provider, con l'IP client originale passato in un header come X-Forwarded-For o CF-Connecting-IP.
Molti prodotti WAF SaaS usano un reverse proxy gestito dal provider o un'integrazione sull'edge, ma non tutti i servizi si attivano con un cambio DNS. Cloudflare, Sucuri e Fastly si posizionano di norma nel percorso della richiesta, sull'edge. AWS WAF si associa invece a CloudFront o a risorse AWS supportate come Application Load Balancer, API di API Gateway e API AppSync. In ogni caso le richieste HTTP(S) vengono valutate prima che l'applicazione protetta le gestisca.
Un WAF ispeziona dati di livello 7 come header delle richieste, percorsi, query string, metodi, cookie e la porzione configurata dei corpi delle richieste. Un firewall di rete tradizionale decide soprattutto ai livelli 3 e 4 usando indirizzi, protocolli e porte. La nostra guida firewall hardware o software copre la distinzione più ampia.
La protezione WAF gestita attinge di solito da tre fonti di regole:
- L'OWASP Core Rule Set (CRS) è una base open source per ModSecurity e i motori WAF compatibili. Copre categorie di attacco comuni come SQL injection, cross-site scripting, command injection e local file inclusion. I prodotti costruiti su ModSecurity spesso includono CRS, mentre molti provider cloud usano invece regole gestite proprietarie.
- I set di regole gestiti dal vendor sono regole proprietarie che il provider tiene aggiornate. Le «Managed Rules» di Cloudflare, le «AWS Managed Rules» di AWS WAF e il feed di threat intelligence di Imperva rientrano qui.
- Le regole personalizzate sono quelle che scrivi tu. «Blocca le richieste verso /admin che non arrivano da questo intervallo IP», «limita /api/login a 5 al minuto per IP».
Una regola anti SQL injection può segnalare un pattern familiare come ' OR 1=1 -- in un parametro di query o nel corpo della richiesta. Questo intercetta le sonde pigre, ma un WAF può comunque mancare payload offuscati, difetti di logica e richieste malevole che assomigliano al normale traffico applicativo. Valuta segnali osservabili della richiesta, non l'intento di business.
Da cosa protegge, in parole semplici:
- Attacchi di injection il cui payload corrisponde a una firma nota
- Traffico di bot proveniente da scanner noti
- Pattern semplici di forza bruta
- DDoS volumetrico, quando il provider gestisce anche lo scrubbing DDoS
- Abuso di API di base
Ciò che non fa:
- Applicare patch alla tua applicazione
- Sostituire la validazione degli input nel tuo codice
- Fermare attacchi che sembrano traffico normale
La sicurezza applicativa continua a venire dall'applicazione. Un WAF alza il pavimento contro attacchi comuni e automatizzati, ma sono codice sicuro, patching, autorizzazione, gestione degli input, monitoraggio e risposta agli incidenti a fissare il soffitto.
WAF SaaS, appliance on-prem o auto-hosting su un VPS
Nel 2026 esistono tre modelli di deployment WAF comuni: WAF SaaS in cloud (Cloudflare, AWS WAF, Fastly e altri), appliance fisiche o virtuali (comprese le offerte F5 e Imperva) e software auto-ospitato su un VPS o su un tuo server.
I tre differiscono su quattro domande pratiche: chi gestisce il piano di ispezione, chi paga la capacità, chi mette a punto le regole e cosa succede quando il WAF blocca qualcosa che non avrebbe dovuto. Il resto dell'articolo usa queste quattro come griglia di confronto.
WAF SaaS in cloud
Instradi il traffico attraverso l'edge del provider oppure associ il WAF a una risorsa cloud supportata. Il provider gestisce la capacità di ispezione e gli aggiornamenti gestiti, mentre tu selezioni le regole, crei policy specifiche per l'applicazione e affini le eccezioni. Tra le opzioni comuni ci sono Cloudflare, AWS WAF, Imperva, Sucuri e Fastly.
Il compromesso: capacità e operatività sono un problema di qualcun altro. Ma ogni richiesta HTTP passa anche per l'infrastruttura di qualcun altro. Il tuo traffico HTTP attraversa l'infrastruttura del provider, e metadati della richiesta o frammenti di payload rilevati possono finire nei log a seconda del provider, del prodotto e delle impostazioni di logging.
WAF su appliance on-prem
Un'appliance fisica o virtuale si posiziona nel percorso della tua rete. Gli acquirenti sono in genere organizzazioni con operazioni di sicurezza di rete consolidate, requisiti di capacità fissa, controlli di deployment stringenti o rapporti già avviati con i vendor. Capacità, aggiornamenti, alta disponibilità e tuning restano a carico del cliente.
Per molti team piccoli e medi, l'acquisto dell'appliance, la capacità fissa e il carico operativo rendono questa la strada meno praticabile. Può comunque adattarsi a organizzazioni che hanno bisogno di un control plane dentro la rete e di personale per gestirlo.
WAF auto-ospitato sul tuo VPS
Installi un WAF su un VPS Linux, punti il DNS a quel VPS e il WAF si mette come reverse proxy davanti alla tua applicazione. Lo gestisci tu. Lo affini tu. Sei tu che ti colleghi alle 2 di notte quando un aggiornamento delle regole gestite blocca una richiesta legittima e non c'è nessun altro da chiamare.
Due progetti open source hanno slancio: SafeLine, un WAF open source che usa un motore di analisi semantica invece del puro matching con espressioni regolari, e BunkerWeb, un WAF basato su NGINX che integra ModSecurity. Licenze, modelli di deployment e impronta sulle risorse sono trattati più avanti, nella sezione sull'auto-hosting.
Il compromesso è l'inverso del modello SaaS. Controlli il piano di ispezione, la capacità, i log e il tuning. Questo riduce la dipendenza da un provider WAF terzo, ma le reti upstream e gli hosting continuano a trasportare il traffico. Limiti infrastrutturali, banda, patching e risposta agli incidenti diventano responsabilità tua.
WAF SaaS o WAF auto-ospitato sul tuo VPS
La tabella comparativa qui sotto si concentra sulle differenze pratiche che i sysadmin devono gestire e mettere a budget.
| Criteri | WAF SaaS in cloud | WAF auto-ospitato su un VPS |
|---|---|---|
| Chi gestisce il piano di ispezione | Il provider, all'edge della rete | Tu, sul tuo VPS |
| Chi paga la capacità | Il provider, che te la rifattura in abbonamento o a richiesta | Tu, costo fisso del VPS |
| Chi mette a punto le regole | Configuri tu; il provider rilascia gli aggiornamenti delle regole gestite | Tu, dall'inizio alla fine |
| Rimedio in caso di falsi positivi | Regolare regole ed eccezioni entro i controlli del provider; scalare i problemi di piattaforma | Modificare la regola da solo; rideployare in pochi minuti |
| Instradamento dei dati | Le richieste passano per l'infrastruttura di ispezione del provider | Le richieste passano per un'infrastruttura che controlli tu prima di raggiungere l'origine |
| Come si comporta il costo durante un picco di traffico | Le componenti a consumo possono crescere con il volume di richieste | Di solito più prevedibile, ma banda e scaling possono comunque aggiungere costi |
| Carico operativo | Bassa, limitata a configurazione e tuning | Gestisci tu il VPS e il WAF |
I prezzi del WAF SaaS nel 2026
Il pricing del WAF SaaS combina di solito livelli in abbonamento, addebiti a consumo o preventivi commerciali. I prezzi pubblici non sono direttamente confrontabili perché ogni provider impacchetta in modo diverso regole gestite, controlli bot, logging, supporto e funzioni anti-DDoS.
| Fornitore | Modello di prezzo | Prezzo di ingresso | Cosa include il livello base | Note |
|---|---|---|---|---|
| Cloudflare | Livello in abbonamento | Gratuito; Pro 20 $/mese annuale o 25 $/mese mensile; Business 200 $/mese annuale o 250 $/mese mensile | Free Managed Ruleset; i controlli più ampi variano in base al piano a pagamento | Verifica regole, limiti e funzioni di sicurezza incluse prima dell'acquisto |
| AWS WAF | A richiesta | $5 per web ACL/month plus $1 per rule or rule group/month plus $0.60 per million requests | Regole gestite da te; le AWS Managed Rules si possono aggiungere come gruppi di regole gestite | Capacità extra, ispezione del body, gruppi gestiti premium, CAPTCHA, Challenge, Bot Control e Fraud Control possono aggiungere costi |
| Imperva | Preventivo enterprise | Contatta il team vendite | Regole gestite, threat intelligence e opzioni di sicurezza API | Nessun prezzo pubblico di WAF self-service direttamente confrontabile |
| Sucuri Platform | Livello in abbonamento | Basic Firewall 9,99 $/mese; Basic Platform 229 $/anno | Piano firewall: WAF/CDN; il bundle Platform aggiunge scansione e pulizia | Il firewall autonomo e il bundle Platform annuale sono prodotti diversi |
| Fastly | Tramite il commerciale | Contatta il team vendite | Ispezione sull'edge o distribuita, regole gestite e protezione delle API | Nessun prezzo pubblico di WAF self-service direttamente confrontabile |
AWS WAF pubblica i prezzi per componente, mentre Cloudflare e Sucuri pubblicano i prezzi dei piani self-service. Imperva e Fastly usano prezzi commerciali per offerte WAF comparabili.
Verificato il 29 luglio 2026: la pagina dei piani Cloudflare indica Pro a 20 $ al mese con fatturazione annuale o 25 $ mensile, e Business a 200 $ al mese annuale o 250 $ mensile. La pagina prezzi del firewall Sucuri lists Basic Firewall at $9.99 per month and Basic Platform at $229 per year. The firewall and platform bundles are different products. The AWS WAF figures above come from il pricing di AWS WAF as of the same date.
Imperva e Fastly non pubblicano prezzi WAF self-service direttamente confrontabili, quindi trattali come opzioni da contattare commercialmente invece di affidarti a stime di terzi.
La pagina prezzi di AWS WAF indica addebiti base di 5 $ per web ACL al mese, 1 $ per regola o gruppo di regole al mese e 0,60 $ per milione di richieste elaborate. Possono applicarsi costi aggiuntivi per capacità extra, ispezione del body più ampia, azioni CAPTCHA o Challenge, gruppi gestiti premium e controlli antifrode o antibot. Il traffico d'attacco può quindi far crescere la bolletta, ma l'impatto dipende da volume, durata e funzioni attive. Le regole rate-based proteggono l'applicazione; non rendono gratuite le richieste WAF già elaborate.
Dove il WAF SaaS mostra i suoi limiti
I falsi positivi sono il primo limite pratico. Un upload legittimo, una chiamata API o l'invio di un form possono somigliare a un pattern d'attacco e far scattare una regola gestita. L'operatore deve poi individuare la regola che ha fatto match, restringerla o escluderla, e verificare che l'eccezione non apra un bypass più ampio.
I WAF decidono in base ai segnali della richiesta, non all'intento di business. Regole rigide possono bloccare traffico legittimo; eccezioni ampie possono indebolire la protezione. I servizi cloud di solito forniscono log degli eventi, override delle regole e risposte personalizzate, ma visibilità e controlli di tuning disponibili variano per piano e provider.
Consiglio da esperti. Avvia le regole nuove o modificate in modo sostanziale in modalità detection o count. Osserva traffico rappresentativo, testa i flussi critici e quelli poco frequenti, passa in rassegna i falsi positivi e aggiungi esclusioni molto mirate prima di attivare il blocco. Le attuali linee guida di tuning del CRS raccomandano una o due settimane, o finché non sono stati esercitati il traffico di picco e i flussi critici.
Il secondo limite è l'overhead prestazionale. Un benchmark ModSecurity del 2023 ha misurato 9.462 upload di file piccoli in 7,36 secondi con CRS attivo contro 4,55 secondi senza. Il throughput è sceso da 2.079 a 1.285 richieste al secondo, mentre il picco di CPU di nginx è salito dall'8 % al 73 %. Era una singola configurazione e un singolo workload: prendilo come prova che l'ispezione ha un costo, non come un rapporto universale di sizing.
Il terzo limite è l'instradamento dei dati. Ogni richiesta HTTP, corpo incluso, passa per l'infrastruttura del provider. Per le applicazioni che trattano dati personali, transazioni finanziarie o dati sanitari, è una questione concreta di sovranità dei dati. Un'applicazione ospitata nell'UE che instrada le richieste dei clienti attraverso un provider WAF statunitense ha una traccia di audit più impegnativa da giustificare, e qualche clausola contrattuale in più da accettare, rispetto alla stessa applicazione con un reverse proxy auto-ospitato su un VPS nella stessa giurisdizione.
Il quarto limite è il carico di tuning. Le difficoltà di tuning di un WAF includono falsi positivi, contesto applicativo limitato e regole che devono stare al passo con cambi di codice frequenti. La fonte è la prospettiva di un vendor, ma lo schema operativo è reale: o i team investono in tuning continuo, oppure lasciano più regole in sola detection.
La stessa critica del 2023 sostiene che i WAF possono diventare teatro della sicurezza quando i team ci si appoggiano invece di sistemare l'applicazione. L'argomento è più forte per i team con sicurezza applicativa matura: accesso parametrizzato al database, autorizzazione solida, scansione regolare delle dipendenze, deployment immutabili e monitoraggio efficace. In ambienti meno maturi un WAF può comunque ridurre l'esposizione alle sonde automatizzate più comuni. Entrambe le cose possono essere vere.
I WAF sono uno strato della difesa in profondità. Non sostituiscono la sicurezza applicativa, e non sono nemmeno teatro della sicurezza. Il valore marginale di un WAF è alto per certi team e basso per altri. A decidere è com'è fatta l'applicazione sotto.
Quando ha senso auto-ospitare un WAF
L'auto-hosting vince in tre situazioni. Perde in altre tre. Prima quelle in cui vince.
L'auto-hosting vince quando vincoli di policy o di sovranità dei dati escludono l'ispezione da parte di un intermediario WAF SaaS esterno, quando i pattern di traffico rendono il pricing a consumo meno conveniente rispetto a un'infrastruttura dedicata, e quando un team vuole controllo diretto sulle decisioni di blocco e sulla correzione dei falsi positivi.
L'auto-hosting perde quando non c'è capacità operativa, quando l'applicazione sta su una piattaforma gestita il cui modello di routing rende scomodo un proxy esterno, oppure quando un piano gratuito gestito dal provider copre già i controlli richiesti con meno complessità.
Il piano Free di Cloudflare può essere un punto di partenza pratico per team piccoli e medi che già usano il suo DNS o la sua CDN e accettano il suo modello di ispezione del traffico. L'auto-hosting diventa più attraente quando l'instradamento dei dati, il controllo diretto delle regole o costi infrastrutturali prevedibili contano più che ridurre al minimo l'operatività.
SafeLine e BunkerWeb
Vale la pena conoscere due WAF open source auto-ospitabili.
SafeLine è rilasciato con licenza GPL-3.0, si distribuisce con Docker Compose ed è costruito attorno all'analisi semantica invece che su un puro ruleset CRS. Il repository di SafeLine dichiara 71,65 % di rilevamento, 0,07 % di falsi positivi e 99,45 % di accuratezza complessiva in modalità Balance, sulla sua valutazione interna da 33.669 campioni. Sono misure fatte dai manutentori del progetto, non un benchmark indipendente, e non vanno generalizzate oltre quel set di test.
BunkerWeb è rilasciato con licenza AGPL-3.0 e usa NGINX sotto il cofano. Integra ModSecurity con l'OWASP Core Rule Set e supporta diversi modelli di deployment, tra cui Linux, Docker, Swarm e Kubernetes.
Dimensiona entrambi i progetti partendo da un volume di richieste misurato, dalle protezioni attive, dal lavoro TLS e dalla retention dei log. Per un deployment SafeLine a basso traffico, 2 vCPU e 4 GB di RAM sono un punto di partenza prudente, con margine sopra il minimo di installazione. L'attuale guida quickstart di BunkerWeb raccomanda almeno 2 vCPU e 8 GB di RAM per test o pochissimi servizi, e 4 vCPU con 16 GB di RAM per ambienti di produzione che proteggono molti servizi. Lo storage dipende soprattutto dal ritmo dei log e dalla retention: misuralo invece di promettere un numero fisso di mesi.
Consiglio da esperti. Fai girare il WAF auto-ospitato nella stessa regione dell'origine dell'applicazione, quando possibile. Un proxy distante aggiunge un round trip di rete interregionale a ogni richiesta e può degradare la latenza in silenzio. Misura il tempo di risposta end-to-end dalle regioni dei tuoi utenti prima del passaggio in produzione.
Il WAF lo gestisci tu, il che significa che anche l'infrastruttura sottostante è responsabilità tua: uptime, patch di sicurezza, certificati TLS, backup, rotazione dei log, monitoraggio, capacità e ripristino. Testa il comportamento in caso di guasto con la stessa cura delle regole di filtro, così il WAF non diventa un single point of failure.
Un Framework Decisionale
Esistono quattro strade: il piano gratuito di Cloudflare, un WAF SaaS cloud a pagamento, un WAF auto-ospitato su un VPS e nessun WAF. La condizione che seleziona ciascuna è diversa.
Scegli un piano WAF cloud gratuito quando le regole gestite e i limiti disponibili corrispondono al rischio dell'applicazione, il modello di instradamento dei dati è accettabile e ridurre al minimo il lavoro operativo è la priorità. Testa flussi reali prima di dare per scontato che i default bastino.
Scegli un WAF SaaS a pagamento quando ti servono più regole gestite, logging, controlli personalizzati, protezione bot o API, supporto o capacità di quanto offra il piano gratuito. Confronta la matrice esatta di funzioni e limiti, non solo il nome del piano. AWS WAF dà il meglio quando l'applicazione usa già risorse AWS supportate e il team se la cava a stimare costi per componente.
Scegli un WAF auto-ospitato quando valgono le condizioni di auto-hosting viste sopra e il tuo team sa gestire il proxy in modo affidabile. SafeLine e BunkerWeb sono i due progetti da valutare per primi.
Nessun WAF può essere una scelta difendibile quando la sicurezza applicativa è matura, l'esposizione è controllata di proposito, il monitoraggio è solido e il rischio residuo è documentato e accettato. Non dovrebbe però diventare il default solo perché un framework valida gli input.
Conclusione
Scegli il WAF SaaS per la capacità gestita dal provider e meno carico operativo. Scegli l'auto-hosting per il controllo diretto, quando il team sa far girare il proxy in modo affidabile. In entrambi i modelli: rilascia le regole a stadi, misura latenza e falsi positivi, e tieni la sicurezza applicativa al primo posto.
Se l'auto-hosting risponde alle tue esigenze, parti da un Linux VPS nella stessa regione dell'origine. Cloudzy offre anche deployment marketplace in un clic per SafeLine e per BunkerWeb, così puoi iniziare a testare senza costruire a mano lo stack di base.
Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.
Vedi piani LinuxDomande frequenti
Che cos'è il WAF as a service?
Il WAF as a service è un web application firewall erogato dal cloud. Il traffico arriva al servizio tramite routing DNS o reverse proxy, integrazione sull'edge o associazione a una risorsa cloud supportata. Il provider gestisce la capacità di ispezione e gli aggiornamenti gestiti; tu scegli le policy, affini le eccezioni e aggiungi regole specifiche per l'applicazione.
Cloudflare è un WAF?
Sì. Cloudflare fornisce funzionalità WAF all'interno di una piattaforma edge più ampia che include anche DNS, CDN e protezione DDoS. I piani gratuiti ricevono il Cloudflare Free Managed Ruleset; ruleset più ampi, controlli, analytics e gestione dei bot dipendono dal piano scelto e dagli add-on.
Il WAF gratuito di Cloudflare basta?
Dipende dalla superficie d'attacco dell'applicazione, dalle regole necessarie, dalle esigenze di logging e retention, dai controlli API o bot, dai requisiti di supporto e dalla tua tolleranza ai falsi positivi. Il Free Managed Ruleset può essere una base utile, ma autenticazione, pagamenti o dati regolamentati non si traducono automaticamente in un preciso piano a pagamento. Confronta gli attuali limiti delle funzioni e validali rispetto al tuo threat model.
Qual è la differenza tra un WAF e un firewall?
Un firewall di rete tradizionale filtra il traffico soprattutto con informazioni di livello 3 e 4: indirizzi, protocolli e porte. Un WAF valuta richieste HTTP(S) di livello 7, inclusi header, percorsi, parametri e contenuti del corpo configurati. I prodotti di sicurezza moderni possono sfumare questi confini, ma i due controlli restano complementari, non intercambiabili.
Che cos'è il WAAP e in cosa differisce da un WAF?
WAAP sta per Web Application and API Protection. È più ampio di un WAF tradizionale: i vendor di solito combinano regole WAF con discovery o enforcement delle API, gestione dei bot e controlli anti-DDoS o anti-abuso a livello applicativo. Il bundle esatto varia da provider a provider, quindi il WAAP non va trattato come un set di funzioni standardizzato.
Mi serve un WAF se il mio framework valida già gli input?
Non sempre. I controlli del framework riducono il rischio, ma non coprono ogni schema di abuso automatizzato. Aggiungi un WAF solo quando risponde a un rischio definito che ne giustifica costo e tuning.
