Se gestisci un sito WordPress e hai installato Wordfence, probabilmente pensi di aver risolto il problema della sicurezza.
Non è così. Wordfence è utile — non è inutile — ma protegge un sistema che rimane strutturalmente vulnerabile. È come installare un antifurto in una casa con le finestre rotte: riduce il rischio, non lo elimina.
Questo articolo spiega cos'è un WAF applicativo, come funziona tecnicamente, e perché la differenza tra un WAF aggiunto come plugin e un WAF integrato nell'architettura del CMS non è una questione di preferenza — è una questione di efficacia reale.
Cos'è un WAF applicativo e cosa fa concretamente
WAF sta per Web Application Firewall. A differenza di un firewall di rete tradizionale — che filtra il traffico basandosi su indirizzi IP e porte — un WAF opera al livello applicativo: analizza il contenuto delle richieste HTTP prima che raggiungano l'applicazione web.
In pratica, ogni richiesta che arriva al tuo sito — una visita alla homepage, la compilazione di un form, una ricerca nel catalogo — passa attraverso il WAF prima di essere elaborata dal CMS. Il WAF analizza il contenuto della richiesta cercando pattern noti di attacco: tentativi di SQL injection, cross-site scripting (XSS), inclusione di file remoti, traversal di directory, e decine di altre tecniche usate dagli attaccanti.
Se la richiesta corrisponde a un pattern di attacco noto, viene bloccata prima che arrivi al codice dell'applicazione. L'attaccante riceve un errore, il tuo database non viene mai interrogato con quella query malevola.
Perché Wordfence non è un WAF applicativo nel senso tecnico del termine
Wordfence si autodefinisce un "endpoint WAF" — e questa distinzione è importante. Non è un WAF applicativo tradizionale: è un plugin PHP che viene eseguito all'interno di WordPress dopo che la richiesta è già entrata nel sistema.
La differenza non è semantica. È operativa.
Un WAF applicativo vero opera davanti all'applicazione — intercetta le richieste prima che il codice PHP di WordPress inizi a elaborarle. Wordfence opera dentro l'applicazione — il codice PHP di WordPress si avvia, carica il plugin, e solo allora Wordfence analizza la richiesta.
Questo significa che esistono categorie di vulnerabilità che Wordfence non può intercettare perché vengono sfruttate prima che il plugin entri in esecuzione. Vulnerabilità nel core di WordPress, vulnerabilità in altri plugin che si caricano prima di Wordfence, attacchi che sfruttano la configurazione del server piuttosto che il codice PHP — tutte situazioni in cui Wordfence è già fuori dal percorso critico quando l'attacco avviene.
Le vulnerabilità che Wordfence non copre
Vulnerabilità nei plugin caricati prima di Wordfence
WordPress carica i plugin in un ordine che non è sempre prevedibile o controllabile. Se un plugin vulnerabile viene caricato prima di Wordfence, l'attacco può avvenire nella finestra tra il caricamento di quel plugin e l'attivazione della protezione. Con installazioni con molti plugin — scenario comune nei siti aziendali — questa finestra esiste concretamente.
Attacchi a livello di server web
Wordfence non vede le richieste che vengono gestite direttamente da NGINX o Apache prima di arrivare a PHP. Attacchi che sfruttano configurazioni errate del server web, directory listing abilitato, file di configurazione accessibili pubblicamente — questi attacchi avvengono a un livello che Wordfence non monitora.
Attacchi di forza bruta distribuiti
Wordfence ha un sistema di rate limiting per gli attacchi brute force, ma opera a livello di singolo server. Un attacco distribuito — migliaia di IP diversi che provano ognuno poche credenziali — può eludere il rate limiting basato su IP. Un WAF applicativo con intelligence distribuita ha una visione più ampia e può identificare pattern di attacco che su un singolo server sembrano traffico normale.
Zero-day nei plugin
Wordfence usa un sistema di firme per identificare attacchi noti. Una vulnerabilità zero-day — scoperta e sfruttata prima che esista una firma di rilevamento — non viene intercettata da Wordfence finché la firma non viene aggiornata. Nelle ore o nei giorni tra la scoperta della vulnerabilità e l'aggiornamento della firma, il sito è esposto.
Come funziona un WAF applicativo nativo nel CMS
Un WAF integrato nel core del CMS — non aggiunto come plugin — opera in modo fondamentalmente diverso.
Prima di tutto, opera prima dell'applicazione. Ogni richiesta viene filtrata prima che qualsiasi codice PHP del CMS inizi a eseguirsi. Non c'è finestra temporale tra il caricamento dell'applicazione e l'attivazione della protezione — la protezione è parte dell'architettura stessa.
Secondo, non dipende da aggiornamenti manuali. Su WordPress, mantenere Wordfence aggiornato è responsabilità tua — o del developer che gestisce il sito. Se l'aggiornamento viene posticipato, le nuove firme di attacco non vengono applicate. Un WAF nativo viene aggiornato dal team che gestisce il sistema, senza che tu debba fare nulla.
Terzo, non aggiunge superficie di attacco. Ogni plugin installato su WordPress è un potenziale vettore — inclusi i plugin di sicurezza. Nel 2023 sono state scoperte vulnerabilità in plugin di sicurezza WordPress con milioni di installazioni. Un WAF nativo non è un plugin: è codice del sistema stesso, scritto e mantenuto dallo stesso team che ha scritto il resto del CMS. L'architettura di sicurezza di KeideaCMS integra WAF, rate limiting, geo-blocking e 2FA nel core — senza dipendenze da terze parti.
Il problema delle regole WAF su Wordfence free vs premium
C'è un dettaglio che Wordfence comunica chiaramente ma che molti utenti ignorano: la versione gratuita di Wordfence riceve le regole di protezione con 30 giorni di ritardo rispetto alla versione premium.
In pratica: quando viene scoperta una nuova vulnerabilità in un plugin WordPress diffuso, gli utenti Wordfence premium ricevono la regola di protezione in tempo reale. Gli utenti della versione gratuita ricevono la stessa protezione un mese dopo. In quel mese, i siti con Wordfence free e il plugin vulnerabile installato sono esposti.
Wordfence premium costa circa 100 dollari l'anno per sito. Aggiungilo al costo del plugin SEO, del plugin di backup, del plugin di cache, e il "gratuito" di WordPress continua a diventare sempre meno gratuito — senza che l'architettura di sicurezza sottostante cambi.
WAF cloud vs WAF applicativo nativo: un'altra distinzione importante
Esiste una terza categoria che vale la pena chiarire: i WAF cloud, come Cloudflare WAF o Sucuri WAF. Questi servizi operano davanti al tuo server — il traffico passa attraverso i loro data center prima di arrivare al tuo hosting — e filtrano le richieste malevole a livello di rete.
I WAF cloud sono più efficaci di Wordfence perché operano prima dell'applicazione. Ma hanno limitazioni proprie: dipendono da un servizio esterno con costi ricorrenti, non hanno visibilità sul codice specifico della tua applicazione, e in caso di falsi positivi bloccano traffico legittimo senza che tu abbia controllo granulare.
Un WAF applicativo nativo — integrato nel codice del CMS — ha visibilità completa sul contesto applicativo. Sa che quella richiesta viene da un utente autenticato, sa che quel parametro è atteso in quel form, sa che quella query è legittima perché corrisponde a un pattern previsto dall'applicazione. Questa visibilità contestuale riduce i falsi positivi e aumenta l'efficacia del rilevamento.
Cosa succede concretamente quando Wordfence non basta
Non è un scenario teorico. Le statistiche sugli attacchi a siti WordPress sono documentate e concrete.
La maggior parte degli attacchi riusciti su WordPress non passa attraverso il pannello admin — passa attraverso vulnerabilità nei plugin. Un plugin con una SQL injection non patchata viene scoperto dai crawler automatici degli attaccanti entro ore dalla pubblicazione della vulnerabilità. Questi crawler non aspettano che Wordfence free riceva la firma aggiornata — attaccano subito.
Il risultato tipico di un'iniezione SQL riuscita: estrazione delle credenziali degli utenti dal database, installazione di una webshell per accesso persistente, uso del server come relay per spam o attacchi ad altri siti. Il tutto spesso senza che il proprietario del sito se ne accorga per settimane.
Se il sito gestisce dati personali — e quasi tutti i siti aziendali lo fanno — questa situazione è una violazione GDPR con obbligo di notifica al Garante entro 72 ore e potenziali sanzioni significative. Abbiamo scritto una guida completa su cosa fare nelle prime 24 ore dopo un attacco — ma è meglio non doverla leggere per necessità.
La domanda che vale la pena porsi
La questione non è "Wordfence sì o no" — è più profonda. È: "sto costruendo la sicurezza del mio sito aziendale sopra un sistema che non è stato progettato per essere sicuro, aggiungendo strati di protezione uno sopra l'altro?"
Wordfence, Sucuri, iThemes Security — sono tutti tentativi di risolvere un problema architetturale con soluzioni applicative. Funzionano, in parte, finché funzionano. Ma non cambiano il fatto che WordPress con plugin è una superficie di attacco distribuita dove ogni componente aggiunto aumenta il rischio complessivo.
Un CMS con sicurezza integrata nel core — WAF nativo, crittografia dei dati, pannello admin separato, zero dipendenze da plugin di sicurezza esterni — risolve il problema dove va risolto: nell'architettura, non nella toppa.
Se vuoi capire concretamente quanto è esposto il tuo sito attuale e cosa cambierebbe con un'infrastruttura progettata per la sicurezza, puoi richiedere un audit gratuito. Puoi anche confrontare direttamente l'approccio alla sicurezza di KeideaCMS e WordPress qui.
