Un sito WordPress compromesso non è solo un problema tecnico. Per un’agenzia che gestisce i siti dei propri clienti, è una crisi che tocca tre fronti contemporaneamente: la fiducia del cliente, la reputazione dell’agenzia e, in molti casi, la conformità al GDPR. Eppure la sicurezza WordPress rimane uno degli ambiti più trascurati nella gestione ordinaria delle agenzie italiane.
Questa guida copre tutto il necessario: dalle vulnerabilità più sfruttate agli attaccanti, alla checklist di hardening pratica, fino al protocollo da seguire quando un sito viene effettivamente compromesso. Ogni sezione è pensata per chi gestisce tra 5 e 50 siti WordPress per conto di clienti terzi.
Perché la Sicurezza WordPress è una Responsabilità Critica per le Agenzie
Gestire siti WordPress per conto dei clienti significa assumersi una responsabilità che va ben oltre la manutenzione tecnica ordinaria.
Il Quadro Legale: GDPR e Responsabilità Contrattuale
Dal punto di vista normativo, quando un’agenzia gestisce un sito che raccoglie dati personali — e quasi tutti lo fanno, anche solo con un form di contatto — il Regolamento Generale sulla Protezione dei Dati (GDPR) impone obblighi precisi. L’articolo 32 richiede che vengano adottate “misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio”. Un breach su un sito mal configurato può tradursi in una notifica all’Autorità Garante obbligatoria entro 72 ore, con sanzioni che raggiungono 10 milioni di euro o il 2% del fatturato globale.
Sul piano contrattuale, molte agenzie non includono nei contratti con i clienti clausole esplicite che definiscano le responsabilità in caso di incidente. Questa lacuna, in caso di violazione, espone l’agenzia a richieste di risarcimento che possono essere tecnicamente fondate.
Il Danno Reputazionale
Un sito cliente compromesso che distribuisce malware ai visitatori, o che viene inserito nelle blacklist di Google, produce conseguenze immediate e visibili. Il sito scompare dai risultati di ricerca. Il browser mostra avvisi che scoraggiano l’accesso. Il cliente perde traffico, lead, vendite. E l’agenzia che gestiva il sito porta la responsabilità morale — e spesso contrattuale — di quanto accaduto.
La fiducia, una volta persa in questo modo, raramente si recupera. Ed è una fiducia che si ripercuote anche sul passaparola: un cliente danneggiato lo dirà ad altri.
Le 10 Vulnerabilità WordPress Più Comuni
Comprendere cosa cercano gli attaccanti è il primo passo per difendersi. Queste sono le vulnerabilità più frequentemente sfruttate sulle installazioni WordPress nel 2026.
1. Plugin e Temi Obsoleti con CVE Note
I plugin WordPress sono il vettore di attacco principale: oltre il 56% delle vulnerabilità WordPress documentate riguarda i plugin. Ogni plugin non aggiornato con una CVE pubblica è un bersaglio attivo. Gli attaccanti scansionano automaticamente milioni di siti alla ricerca di versioni vulnerabili. Il tempo tra la pubblicazione di una CVE e il primo tentativo di exploit automatizzato si misura in ore, non in giorni.
2. Credenziali Deboli e Brute Force
L’endpoint /wp-login.php è pubblicamente accessibile per default. I bot eseguono attacchi di brute force continui combinando liste di username comuni (admin, administrator, nome del sito) con dizionari di password. Un sito senza protezione brute force riceve in media migliaia di tentativi di login al giorno.
3. SQL Injection attraverso Plugin
Le query SQL costruite dinamicamente senza sanitizzazione corretta permettono a un attaccante di estrarre o modificare dati nel database. Molti plugin WordPress di terze parti — specialmente quelli poco mantenuti — contengono vulnerabilità SQL injection non ancora patchate.
4. Cross-Site Scripting (XSS) Riflesso e Persistente
Lo XSS permette di iniettare codice JavaScript malevolo nelle pagine del sito. Lo XSS persistente è particolarmente pericoloso: il codice viene salvato nel database e viene eseguito ogni volta che la pagina viene visitata, permettendo di rubare cookie di sessione, reindirizzare utenti o distribuire malware ai visitatori.
5. File Upload non Validato
I form di upload file che non verificano il tipo e il contenuto del file caricato possono permettere l’upload di file PHP eseguibili. Una volta caricato un webshell, l’attaccante ha accesso alla shell del server con i permessi del processo web.
6. XML-RPC Abuse
Il protocollo XML-RPC di WordPress, accessibile su /xmlrpc.php, supporta autenticazione e permette operazioni sul sito. Viene abusato in due modi: attacchi brute force massivi (ogni richiesta può tentare migliaia di combinazioni) e amplificazione DDoS. Se non si usa XML-RPC, va disabilitato.
7. Directory Listing Abilitato
Se il server web non restituisce un index.php o index.html in una directory, molte configurazioni mostrano il contenuto della directory. Questo espone strutture di file, backup, file di log e altri contenuti sensibili che non dovrebbero essere pubblicamente accessibili.
8. wp-config.php non Protetto
Il file wp-config.php contiene le credenziali del database, le chiavi di sicurezza e altre informazioni critiche. Se accessibile via web o se i permessi del file system sono errati, può essere letto da processi non autorizzati o, in scenari peggiori, scaricato direttamente.
9. Enumerazione Utenti
WordPress, per default, espone gli username degli autori tramite le URL /wp-json/wp/v2/users e il parametro ?author=1. Gli attaccanti usano questa informazione per ridurre lo spazio di ricerca negli attacchi brute force, sapendo già il nome utente corretto.
10. Dipendenze PHP e Server non Aggiornate
Le vulnerabilità non si limitano a WordPress stesso. PHP con versioni EOL (end of life), server web non patchati, librerie di terze parti obsolete: l’intera stack tecnologica è superficie di attacco. PHP 7.x non riceve aggiornamenti di sicurezza dal dicembre 2022; i siti che girano ancora su PHP 7.4 sono esposti a CVE mai risolte.
Checklist di Hardening WordPress: 15 Punti Operativi
Questa checklist va applicata sistematicamente a ogni nuovo sito client e verificata periodicamente su quelli esistenti.
Configurazione Base
1. Aggiornare PHP all’ultima versione stabile supportata
Verificare che l’hosting esegua PHP 8.2 o superiore. PHP 8.1 riceve ancora aggiornamenti di sicurezza, ma 8.2+ è preferibile.
2. Cambiare il prefisso tabelle del database
Il prefisso wp_ standard facilita gli attacchi SQL injection. Durante l’installazione — o tramite plugin come Better WP Security — usare un prefisso personalizzato come ap8x3_.
3. Spostare wp-config.php fuori dalla document root
WordPress cerca wp-config.php anche nella directory superiore alla root. Spostarlo riduce il rischio di accesso accidentale.
4. Impostare i permessi file corretti
# Directory: 755
find /var/www/sito-cliente -type d -exec chmod 755 {} \;
# File: 644
find /var/www/sito-cliente -type f -exec chmod 644 {} \;
# wp-config.php: 440 (solo proprietario + gruppo in lettura)
chmod 440 /var/www/sito-cliente/wp-config.php
5. Aggiungere le chiavi di sicurezza in wp-config.php
Generare chiavi nuove da https://api.wordpress.org/secret-key/1.1/salt/ e inserirle in wp-config.php. Cambiarle dopo ogni incidente di sicurezza per invalidare tutte le sessioni attive.
Protezione degli Accessi
6. Disabilitare XML-RPC
In .htaccess (Apache):
# Blocca XML-RPC completamente
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
In nginx.conf:
location = /xmlrpc.php {
deny all;
return 403;
}
7. Disabilitare l’enumerazione utenti
Aggiungere a functions.php o a un plugin site-specific:
// Blocca enumerazione utenti via REST API
add_filter('rest_endpoints', function($endpoints) {
if (isset($endpoints['/wp/v2/users'])) {
unset($endpoints['/wp/v2/users']);
}
if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
}
return $endpoints;
});
// Blocca enumerazione via ?author=
add_action('template_redirect', function() {
if (is_author()) {
wp_redirect(home_url(), 301);
exit;
}
});
8. Limitare i tentativi di login
Installare un plugin per la protezione brute force (vedi sezione successiva) oppure configurare il rate limiting a livello server.
9. Abilitare l’autenticazione a due fattori per gli amministratori
Plugin come WP 2FA o Google Authenticator for WordPress aggiungono un secondo fattore per tutti i ruoli con capacità amministrative.
10. Limitare l’accesso a wp-admin per IP
Limitare l’accesso a /wp-admin/ per IP specifici in .htaccess (praticabile solo se l’agenzia usa IP statici):
<Directory /var/www/sito-cliente/wp-admin>
Order Deny,Allow
Deny from all
Allow from 1.2.3.4
</Directory>
Header di Sicurezza HTTP
11. Configurare gli security header
In Nginx:
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
12. Configurare una Content Security Policy (CSP)
La CSP è la difesa più efficace contro lo XSS. Richiede test accurati ma vale l’investimento:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted-cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com;" always;
Configurazione Server
13. Disabilitare la visualizzazione degli errori PHP in produzione
In wp-config.php:
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true); // Log in wp-content/debug.log
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
14. Proteggere i file sensibili via .htaccess
# Blocca accesso a file sensibili
<FilesMatch "\.(htaccess|htpasswd|ini|log|sh|sql|bak)$">
Order Allow,Deny
Deny from all
</FilesMatch>
# Blocca accesso diretto a wp-config.php
<Files wp-config.php>
Order Deny,Allow
Deny from all
</Files>
# Disabilita directory listing
Options -Indexes
15. Forzare HTTPS e HSTS
Assicurarsi che tutto il traffico passi su HTTPS con certificato valido (Let’s Encrypt), con redirect automatico da HTTP e header HSTS configurato.
Plugin e Strumenti di Sicurezza Consigliati
Sul mercato esistono diversi plugin di sicurezza WordPress di qualità. Ecco un confronto oggettivo per aiutare l’agenzia a scegliere in base alle esigenze.
Wordfence Security
Wordfence è il plugin di sicurezza WordPress più diffuso, con oltre 5 milioni di installazioni attive. Offre un Web Application Firewall (WAF) con regole aggiornate in tempo reale, scanner malware che analizza file core, plugin e temi, protezione brute force con blocco IP automatico, e un sistema di alert via email.
Punti di forza: Database delle firme malware ampio e aggiornato frequentemente. Interfaccia dettagliata con informazioni sul traffico in tempo reale. Versione gratuita funzionale per installazioni singole.
Limiti: In ambienti multi-sito, la gestione centralizzata richiede Wordfence Central (gratuito ma con funzionalità limitate). Può incidere sulle performance su hosting condivisi. Le regole del firewall in tempo reale richiedono la licenza premium.
Ideale per: Siti singoli o piccoli gruppi dove si desidera un controllo granulare direttamente nell’installazione WordPress.
Sucuri Security
Sucuri offre sia un plugin WordPress gratuito che un servizio cloud a pagamento. Il plugin gratuito gestisce monitoraggio dell’integrità dei file, log delle attività di sicurezza, notifiche post-hack e alcune hardening features. Il servizio cloud aggiunge un WAF a livello DNS — tutto il traffico passa attraverso i server Sucuri prima di raggiungere il sito — e un CDN.
Punti di forza: Il WAF cloud è particolarmente efficace perché blocca il traffico prima che raggiunga il server. Include pulizia malware garantita nei piani a pagamento. Dashboard centralizzata per più siti.
Limiti: Le funzionalità più importanti richiedono il piano a pagamento (da 199 dollari/anno per sito). Il WAF cloud richiede la modifica dei DNS del sito.
Ideale per: Siti ad alto rischio o alto valore dove si giustifica l’investimento in un WAF cloud. Agenzie che gestiscono siti e-commerce o con dati sensibili.
Solid Security (ex iThemes Security)
Rebrandato come Solid Security, questo plugin si distingue per una configurazione guidata che copre oltre trenta punti di sicurezza. Funzionalità chiave: autenticazione a due fattori integrata, rilevamento modifiche file, protezione brute force con blocco IP automatico, gestione delle password utente, log degli accessi.
Punti di forza: Configurazione iniziale rapida tramite wizard. Buona copertura delle hardening features di base. Versione Pro include geolocation IP e report avanzati.
Limiti: Alcune funzionalità del plugin gratuito sono state spostate nella versione Pro nel corso degli anni. Meno efficace di Wordfence nel rilevamento malware attivo.
Ideale per: Agenzie che vogliono un setup rapido e standardizzabile su più siti con configurazione minima.
Quando NON affidarsi solo ai Plugin
I plugin di sicurezza WordPress sono strumenti utili ma non sostituiscono una corretta configurazione del server. Un plugin di sicurezza gira all’interno di WordPress: se un attaccante compromette il server a livello più basso — accesso FTP, vulnerabilità PHP, exploit del server web — il plugin non può fare nulla. L’hardening a livello server rimane la priorità.
Monitoraggio Continuo: Come Automatizzare la Sicurezza
La sicurezza non è uno stato da raggiungere una volta: è un processo continuo. Per un’agenzia che gestisce decine di siti, l’automazione del monitoraggio è l’unico approccio sostenibile.
Vulnerability Scanning Automatico
Un vulnerability scanner per WordPress verifica regolarmente:
- Versioni di WordPress, plugin e temi confrontate con database CVE pubblici (WPScan DB, NVD)
- File core modificati rispetto all’hash ufficiale (potenziale segno di compromissione)
- Plugin e temi abbandonati — non aggiornati da oltre 12 mesi — che rappresentano un rischio latente
Eseguire una scansione manuale su ogni sito periodicamente è impossibile da mantenere sopra i dieci siti. La soluzione è uno strumento che esegue le scansioni automaticamente e notifica solo in caso di problemi.
Uptime e Anomaly Monitoring
Il monitoraggio dell’uptime è il controllo più basilare, ma va integrato con alert sulle anomalie di comportamento:
- Downtime: il sito non risponde o restituisce errori 5xx
- Redirect anomali: il sito reindirizza verso URL esterne non previste (classico sintomo di compromissione)
- Contenuto modificato: la homepage o pagine chiave hanno contenuto diverso dall’ultima scansione
- Certificato SSL: scadenza imminente o certificato non valido
Log Analysis
I log del server web sono una fonte di informazioni preziose per rilevare attività sospette. Esempi di pattern da monitorare:
# Tentativi di accesso a wp-login.php da IP diversi
grep "wp-login.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
# Richieste a file PHP in directory upload (possibili webshell)
grep "uploads.*\.php" /var/log/nginx/access.log
# Richieste con status 500 (possibili exploit falliti)
grep " 500 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
Per un’agenzia che gestisce molti siti, l’analisi manuale dei log non è praticabile. Strumenti come Fail2Ban possono bloccare automaticamente gli IP che mostrano comportamenti anomali nei log.
Monitoraggio delle Blacklist
Un sito compromesso può finire nelle blacklist di Google Safe Browsing, McAfee SiteAdvisor, o Spamhaus. Questo ha conseguenze immediate sulla visibilità nei motori di ricerca e sulla reputazione email del dominio. Verificare periodicamente lo stato del sito nelle principali blacklist fa parte del monitoraggio di sicurezza standard.
Incident Response: Cosa Fare Quando un Sito Viene Compromesso
Quando un sito cliente viene compromesso, le prime ore sono critiche. Avere un protocollo definito in anticipo riduce il tempo di risposta e limita i danni.
Fase 1: Rilevamento e Classificazione (0-30 minuti)
Prima di qualsiasi azione, raccogliere informazioni per capire la natura e l’estensione del problema:
- Identificare come è stata rilevata la compromissione (alert automatico, segnalazione del cliente, Google Search Console, scansione)
- Determinare i sintomi visibili: redirect anomali, contenuto modificato, avvisi browser, presenza in blacklist
- Verificare la data dell’ultima modifica dei file PHP principali
- Controllare i log di accesso per attività anomale nelle 48-72 ore precedenti
Fase 2: Contenimento (30-60 minuti)
L’obiettivo in questa fase è bloccare la propagazione del danno senza distruggere le prove:
- Attivare la modalità manutenzione sul sito per bloccare l’accesso ai visitatori e interrompere la distribuzione di eventuale codice malevolo
- Non eliminare immediatamente i file sospetti: fare prima un backup completo dello stato corrente (include la compromissione, utile per l’analisi forense)
- Revocare tutti gli accessi attivi: cambiare tutte le password (WordPress admin, FTP, SSH, database, hosting panel)
- Invalidare le sessioni WordPress cambiando le chiavi di sicurezza in
wp-config.php
Fase 3: Analisi e Pulizia (1-4 ore)
Identificare il vettore di attacco. I comandi seguenti aiutano a trovare file PHP modificati di recente e pattern comuni di codice malevolo iniettato:
# Trovare file PHP modificati di recente
find /var/www/sito-cliente -name "*.php" -newer /var/www/sito-cliente/wp-login.php -type f
# Cercare funzioni pericolose nei file di upload (indicatori di webshell)
grep -r "base64_decode" /var/www/sito-cliente/wp-content/uploads/
grep -r "system(" /var/www/sito-cliente/wp-content/
grep -r "passthru(" /var/www/sito-cliente/wp-content/
Opzione A — Ripristino da backup: Se esiste un backup pulito con data certa anteriore alla compromissione, il ripristino è l’opzione più sicura e rapida. Verificare che il backup sia effettivamente pulito prima di ripristinarlo.
Opzione B — Pulizia manuale:
- Reinstallare i file core di WordPress scaricandoli direttamente da wordpress.org
- Reinstallare tutti i plugin e i temi dalle fonti ufficiali (non dai backup se potenzialmente compromessi)
- Ispezionare il database alla ricerca di contenuti JavaScript iniettati nei post e nelle opzioni (
wp_options,wp_posts) - Rimuovere eventuali utenti amministratori non autorizzati dalla tabella
wp_users
Fase 4: Hardening Post-Incidente (1-2 ore)
Dopo la pulizia, prima di riaprire il sito:
- Applicare tutti gli aggiornamenti in sospeso (plugin, temi, WordPress core)
- Verificare e correggere i permessi file
- Applicare o ricontrollare l’intera checklist di hardening
- Configurare o aggiornare il Web Application Firewall
Fase 5: Ripristino e Comunicazione
Riaprire il sito solo dopo aver verificato la pulizia con almeno un secondo scanner (non usare solo lo stesso strumento che ha rilevato il problema inizialmente).
Comunicazione al cliente: Informare il cliente in modo chiaro e tempestivo, anche quando è scomodo. Spiegare cosa è successo, quali dati potrebbero essere stati esposti, cosa è stato fatto per risolvere il problema. In base alla natura dei dati coinvolti, potrebbe essere necessario valutare la notifica al Garante Privacy entro 72 ore.
Fase 6: Post-Mortem (entro 48 ore)
Documentare l’incidente: vettore di attacco identificato, timeline degli eventi, azioni intraprese, misure preventive aggiunte. Il post-mortem non serve per trovare colpevoli ma per migliorare i processi e prevenire incidenti analoghi in futuro.
Come AgencyPilot Automatizza la Sicurezza per le Agenzie
Applicare manualmente la checklist di hardening su ogni sito, monitorare continuamente le vulnerabilità, e rispondere prontamente agli incidenti sono attività che richiedono tempo e attenzione. Su scala — quando i siti gestiti sono venti, trenta, cinquanta — questa gestione manuale non è sostenibile.
Le funzionalità di sicurezza di AgencyPilot sono progettate specificamente per questo problema.
Security scanning automatico: AgencyPilot esegue scansioni periodiche delle installazioni WordPress dei clienti, confrontando le versioni di plugin e temi con i database CVE aggiornati. Quando viene rilevata una vulnerabilità nota, l’agenzia riceve un alert immediato con il dettaglio del problema e le azioni raccomandate — senza dover aprire manualmente ogni singola installazione.
Monitoraggio uptime e anomalie: Il sistema verifica costantemente che i siti rispondano correttamente, rilevando non solo il downtime ma anche i redirect anomali che sono spesso il primo segnale visibile di una compromissione.
Alert configurabili per cliente: È possibile definire soglie di allarme personalizzate per ogni cliente: frequenza delle scansioni, gravità minima delle vulnerabilità per cui ricevere notifica, canali di notifica preferiti.
Report di sicurezza per i clienti: I report AI generati da AgencyPilot includono una sezione dedicata alla sicurezza, traducendo i risultati tecnici in linguaggio comprensibile per il cliente finale. Questo trasforma l’attività di sicurezza da costo nascosto a valore comunicato e percepito.
Come spiegato nella nostra guida comparativa tra le principali piattaforme di gestione WordPress, la capacità di comunicare il valore della sicurezza al cliente è uno dei differenziatori più importanti tra le piattaforme disponibili sul mercato.
Storico degli incidenti: Ogni evento di sicurezza viene registrato per sito, creando uno storico che facilita le analisi post-mortem e dimostra al cliente la vigilanza continua dell’agenzia nel tempo.
Conclusioni
La sicurezza WordPress non è una configurazione da fare una volta sola. È una disciplina operativa che richiede attenzione continua, processi definiti e strumenti adeguati.
Per un’agenzia che gestisce siti per conto di clienti, il punto di partenza è sempre lo stesso: applicare sistematicamente la checklist di hardening a ogni nuova installazione, mantenere plugin e temi aggiornati, e avere un piano di incident response pronto prima di averne bisogno.
I punti essenziali da portare via da questa guida:
- Le vulnerabilità nei plugin sono il vettore di attacco principale: aggiornare tempestivamente non è opzionale
- L’hardening a livello server precede e supera in efficacia qualsiasi plugin di sicurezza
- Il monitoraggio continuo e automatizzato è l’unico approccio scalabile su più siti
- Un protocollo di incident response definito in anticipo riduce il danno quando si verifica un incidente
- La comunicazione trasparente con il cliente durante e dopo un incidente è parte integrante della gestione professionale
Se gestisci più di cinque siti WordPress per clienti e stai ancora monitorando manualmente la sicurezza, il costo nascosto di questo approccio — in tempo, in rischio reputazionale, in esposizione legale — supera di gran lunga il costo di una piattaforma dedicata.
Scopri come AgencyPilot automatizza il monitoraggio della sicurezza per la tua agenzia — il setup richiede meno di dieci minuti per sito.
FAQ
Quali sono i passi fondamentali per mettere in sicurezza WordPress?
I passi essenziali sono: mantenere WordPress core, plugin e temi sempre aggiornati; usare password forti e autenticazione a due fattori; cambiare il prefisso delle tabelle del database; disabilitare l’editor di file dal backend; limitare i tentativi di login; installare un plugin di sicurezza come Wordfence o Solid Security; configurare le regole .htaccess per proteggere wp-config.php e la directory wp-includes; e avere backup automatici frequenti.
Come proteggere il login di WordPress dagli attacchi brute force?
Le misure efficaci sono: limitare i tentativi di login falliti con un plugin come Login LockDown o le funzionalità integrate di Wordfence; implementare l’autenticazione a due fattori (2FA); cambiare l’URL di login da /wp-admin a un URL personalizzato; aggiungere HTTP Basic Auth come secondo livello davanti alla pagina di login; bloccare IP che hanno troppi tentativi falliti tramite regole .htaccess o firewall applicativo.
Come configurare correttamente i permessi dei file WordPress?
I permessi corretti sono: 755 per le directory, 644 per i file, 600 per wp-config.php. Mai usare 777 su directory o file in produzione. Il proprietario dei file deve essere l’utente del web server (www-data su Nginx/Apache Debian), non root. Verifica i permessi con il comando: find /percorso/wordpress -type f -name “*.php” -not -perm 644.
Plugin di sicurezza WordPress: quale scegliere tra Wordfence e Solid Security?
Wordfence include un Web Application Firewall (WAF) con regole aggiornate in tempo reale, scanner di malware, blocco IP in tempo reale e protezione brute force. Solid Security (ex iThemes Security) si concentra su hardening della configurazione, 2FA, rilevamento modifiche ai file e protezione del database. Per siti con molto traffico, Wordfence ha un impatto sulle performance maggiore. Per siti small-medium, entrambi sono validi — la scelta dipende da quale funzionalità prioritizzi.