Plugin di sicurezza WordPress: quali servono davvero, quali sono sovrapposti e perché tre plugin fanno meno danni di uno

La scena è ricorrente. Un cliente arriva con un WordPress che ha installato Wordfence, iThemes Security, e un terzo plugin di sicurezza — perché più è meglio di meno, no? Il sito è lento, il login admin impiega 4 secondi a caricare, e ogni tanto un plugin blocca un'azione legittima dell'altro. La domanda che ci si dovrebbe fare non è "quanti plugin di sicurezza servono" ma "cosa fanno davvero, e cosa si sovrappone". La risposta, quasi sempre, è che tre plugin fanno meno danni di uno solo ben configurato.

Il malinteso di fondo è che un plugin di sicurezza e un WAF facciano la stessa cosa. Non è così. Un plugin di sicurezza agisce dentro WordPress — dopo che la richiesta è arrivata al server, è stata processata da PHP, e sta per essere gestita dall'applicazione. Un WAF agisce prima, a livello di server o di rete, e ferma il traffico malevolo prima che raggiunga WordPress. La differenza non è sottile: un plugin che scansiona i file ogni ora non ferma un attacco in tempo reale; un WAF con regole aggiornate sì.

Cosa fa davvero un plugin di sicurezza

Un plugin di sicurezza serio fa principalmente tre cose. La prima è la scansione dei file: confronta i file core e dei plugin con checksum noti e segnala modifiche — utile per individuare backdoor e file iniettati. La seconda è il login protection: limita i tentativi di password (rate limiting su wp-login), forza 2FA, reCAPTCHA. La terza è il monitoraggio del traffico admin: registra chi accede, da dove, e cosa modifica. Queste sono funzioni che un WAF non fa, perché vivono dentro l'applicazione.

Quello che un plugin non fa bene — o fa peggio di un WAF — è fermare gli attacchi volumetrici. Un brute force con 10.000 IP diversi non lo ferma il rate limiting per IP di un plugin, perché ogni IP fa pochi tentativi. Lo ferma un WAF con regole di comportamento (challenge JS, reputation IP) che riconosce il pattern. Per questo i due livelli non si escludono — si completano, ma con compiti diversi.

La configurazione minimale che copre il 90%

Dopo averne viste a centinaia, la configurazione che copre la maggior parte dei rischi reali è sorprendentemente semplice. Un plugin di sicurezza per la scansione file e il login protection, un WAF server-side per il traffico malevolo, e un po' di hardening manuale. Niente di più. Ecco l'hardening di base che si applica nel file wp-config.php e che riduce la superficie di attacco senza plugin:

// wp-config.php — hardening di base

// Disabilita l'editor di file e temi dal backend (nessuno
// dovrebbe editare PHP dall'admin in produzione)
define( 'DISALLOW_FILE_EDIT', true );

// Disabilita installazione/aggiornamento di plugin e temi
// dall'admin (gli aggiornamenti vanno gestiti via FTP/SFTP)
define( 'DISALLOW_FILE_MODS', true );

// Rimuovi i metadati WordPress dall'header (fingerprinting)
remove_action( 'wp_head', 'wp_generator' );

// Disabilita XML-RPC se non lo usi (brute force via multicall)
add_filter( 'xmlrpc_enabled', '__return_false' );

// Limita le revisioni (riduce il gonfiamento del database)
define( 'WP_POST_REVISIONS', 3 );

Perché due plugin sono peggio di uno

Il problema con i plugin multipli non è solo il rallentamento — è l'interferenza. Due plugin che fanno login protection possono entrambi limitare i tentativi, ma con soglie diverse: uno blocca a 5 tentativi, l'altro a 3, e il risultato è che un utente legittimo si ritrova bloccato senza capire perché. Due scanner di file possono entrambi segnalare lo stesso file come sospetto, generando falsi positivi doppi e allarmi continui. E ogni plugin carica i suoi script, le sue tabelle nel database, i suoi cron — il sito si appesantisce in modo cumulativo.

Il caso peggiore è quando due plugin gestiscono il firewall a livello applicazione. Entrambi intercettano le richieste, entrambi valutano le regole, e un payload legittimo (un webhook di pagamento, un'API di un CRM) viene bloccato da uno dei due senza che l'altro lo sappia. Il debug diventa un incubo: quale plugin ha bloccato? Perché? Disabiliti uno, funziona; lo riabiliti, si rompe di nuovo. La regola operativa è una sola: un plugin di sicurezza per funzione, non di più.

Cosa spetta al WAF (e perché non lo fa il plugin)

Il WAF — che sia Cloudflare, mod_security sul server, o il WAF integrato in un hosting WordPress gestito — fa il lavoro che un plugin non può fare: analizza il traffico prima che raggiunga PHP. Le regole aggiornate riconoscono pattern di attacco noti (SQL injection, XSS, RCE) e li bloccano a livello di rete. Il vantaggio non è solo la velocità di blocco — è che il traffico malevolo non consuma risorse del server, perché non arriva mai a WordPress.

Un plugin di sicurezza che fa da firewall applicativo è meglio di niente, ma è un firewall che gira dentro la casa che sta proteggendo. Se l'attacco è volumetrico, il server lavora comunque per processare ogni richiesta prima che il plugin la valuti. Un WAF server-side è il guardiano fuori dalla porta: il traffico malevolo non entra nemmeno.

Il setup che consigliamo

Per la maggior parte dei siti WordPress aziendali, il setup che regge è questo: un WAF server-side (Cloudflare o l'equivalente dell'hosting gestito) per il traffico di rete, un plugin di sicurezza per la scansione file e il login protection (Wordfence o iThemes, uno solo), 2FA forzata sugli account amministrativi, e l'hardening di base nel wp-config.php. Niente di più. Se serve monitoraggio avanzato, si aggiunge un servizio di log esterno — non un quarto plugin.

La sicurezza di WordPress non si misura in numero di plugin installati. Si misura in superficie di attacco ridotta, aggiornamenti tempestivi, backup verificati e monitoraggio che avvisa prima del danno. Tre plugin che si sovrappongono danno l'illusione della sicurezza e il costo reale di un sito lento e instabile. Uno ben configurato, con un WAF e un po' di hardening, copre meglio con meno peso.