Sicurezza WordPress: checklist pratica per proteggere sito, login, plugin e backup
La sicurezza WordPress non dipende dall’installazione di un singolo plugin. Dipende dalla riduzione dei punti deboli più frequenti: componenti non aggiornati, account amministrativi inutili, credenziali riutilizzate, backup non verificati e regole di protezione che bloccano anche funzioni legittime.
Questa è una guida preventiva per piccoli siti, freelance e professionisti. Se il sito mostra già segnali di compromissione, come reindirizzamenti sospetti, nuovi amministratori o file modificati senza motivo, serve una procedura di contenimento e bonifica, non una normale attività di manutenzione.
Completa prima le azioni essenziali. Le misure consigliate e avanzate vanno valutate in base a hosting, e-commerce, aree riservate e integrazioni presenti.
1. Parti dall’inventario: cosa è installato, chi accede e quali servizi dipendono dal sito
Prima di aggiornare, disattivare plugin o creare regole WAF, raccogli le informazioni che descrivono il sito. Una protezione applicata senza conoscere le dipendenze può interrompere un checkout, un webhook o l’accesso da app mobile.
Cosa censire prima di intervenire
- Versione di WordPress e versione PHP.
- Plugin e temi attivi, inattivi e installati manualmente.
- Licenze, canali di aggiornamento e supporto di plugin o temi premium.
- Account amministrativi, ruoli utenti e account non più necessari.
- Email usata per recupero password e notifiche amministrative.
- Modalità, destinazione e storico dei backup.
- Hosting, ambiente di staging, CDN o WAF e strumenti di monitoraggio.
- Integrazioni che usano REST API, XML-RPC, Jetpack, app mobili, webhook, pagamenti, aree riservate o SSO.
Conserva questo inventario in un luogo separato dal sito. Sarà utile anche durante un cambio di fornitore, un aggiornamento critico o il recupero da un errore.
Checklist iniziale per livelli
| Livello | Azione | Rischio ridotto | Come verificare | Possibili effetti collaterali |
|---|---|---|---|---|
| Essenziale | Censire componenti, utenti, backup e integrazioni | Modifiche applicate alla cieca | Esiste un elenco aggiornato | Nessuno |
| Essenziale | Rimuovere account e componenti inutili | Superficie d’attacco superflua | Testare le funzioni collegate prima della rimozione | Possibili dipendenze non documentate |
| Consigliato | Usare staging prima di aggiornamenti critici | Disservizi in produzione | Aggiornamento e flussi principali funzionano nello staging | Richiede hosting o procedura adeguati |
| Avanzato | Applicare WAF e rate limiting mirati | Brute force e traffico automatizzato | Testare login, API, moduli e checkout | Falsi positivi e blocco integrazioni |
2. Aggiorna WordPress e riduci plugin e temi non necessari
Il mantenimento aggiornato di core, plugin e temi è indicato dalla documentazione WordPress come una delle principali misure di sicurezza. Le estensioni meritano particolare attenzione: Patchstack, azienda specializzata in sicurezza, riporta che tra le vulnerabilità registrate nell’ecosistema WordPress nel 2025 la maggior parte riguardava plugin e temi. Non è una misura del rischio di un singolo sito, ma spiega perché inventario e manutenzione vengono prima di molte impostazioni tecniche.
Come valutare plugin e temi
Non conta il numero assoluto di plugin. Un sito con poche estensioni abbandonate può essere più esposto di uno con più plugin, ma mantenuti, necessari e aggiornabili.
Per ogni componente chiediti se svolge una funzione necessaria, se proviene dal repository ufficiale o dal produttore originale, se riceve aggiornamenti, se ha documentazione e changelog consultabili e se è compatibile con la versione di WordPress in uso. Verifica anche eventuali duplicazioni: una funzione già inclusa nell’hosting, nel tema o in un altro plugin non dovrebbe essere gestita inutilmente da una seconda estensione.
Repository ufficiale e popolarità sono segnali utili, non garanzie assolute. Per i prodotti premium controlla licenza, canale di distribuzione e procedura di aggiornamento: l’assenza di avvisi nella bacheca non prova che il componente sia aggiornato.
Disattiva, verifica e rimuovi
Disattiva un plugin o un tema che non serve più, verifica le pagine e le funzioni che potrebbero dipenderne, poi rimuovilo. Non lasciare inattivi a tempo indeterminato plugin e temi che non prevedi di riutilizzare. Mantieni soltanto ciò che puoi aggiornare e controllare.
Aggiornamenti automatici: cosa automatizzare e cosa testare
Gli aggiornamenti minori e di sicurezza del core vengono normalmente gestiti in background da WordPress. Gli aggiornamenti automatici di plugin e temi possono essere selezionati dall’interfaccia; anche gli aggiornamenti maggiori del core possono essere configurati nelle installazioni recenti. L’automazione, però, richiede backup funzionanti, notifiche controllate e attività pianificate di WordPress (WP-Cron) operative.
- Core, patch e aggiornamenti minori: in genere da mantenere automatici, salvo esigenze tecniche documentate.
- Plugin affidabili e poco critici: gli auto-update possono essere ragionevoli se è disponibile un rollback.
- E-commerce, pagamenti, builder e integrazioni: prova prima l’aggiornamento in staging, quando possibile.
- Componenti premium manuali: aggiorna dal canale ufficiale dopo aver controllato compatibilità e licenza.
Per esempio, un aggiornamento del plugin di pagamento andrebbe testato con login, carrello, checkout e notifiche prima di essere portato sul sito pubblico.
3. Proteggi account amministrativi, password e recupero dell’accesso
Un account amministratore compromesso può modificare plugin, utenti e contenuti. Applica quindi il principio dei privilegi minimi: ogni persona deve avere soltanto il ruolo necessario al proprio lavoro.
Meno amministratori, ruoli corretti e account separati
Elimina gli account di ex collaboratori e limita il numero di amministratori. Evita username prevedibili come admin. Per pubblicare articoli o gestire attività quotidiane, usa quando possibile un account con privilegi inferiori e conserva quello amministrativo per gli interventi che lo richiedono.
Controlla anche che l’indirizzo email degli amministratori riceva davvero messaggi di recupero password e avvisi tecnici. Se le email di sistema sono poco affidabili, la configurazione di SPF, DKIM e DMARC merita un approfondimento separato.
Password uniche, password manager e 2FA
Ogni amministratore dovrebbe usare una password lunga, unica e conservata in un password manager. La riutilizzazione di una password esposta da un altro servizio rende inefficaci molte difese del sito.
Attiva inoltre la 2FA per tutti gli amministratori. WordPress non la integra nativamente, quindi occorre una soluzione compatibile tramite plugin o sistema di identità esterno. Dopo l’attivazione, prova il login con il secondo fattore, conserva i recovery code fuori dal sito e predispone almeno un secondo dispositivo o metodo di accesso per gli account privilegiati.
Passkey e Application Passwords: usi diversi
Quando la soluzione adottata le supporta, le passkey basate su WebAuthn sono una valida opzione per gli account privilegiati: NIST le include tra gli esempi di autenticazione resistente al phishing. Non sono però una funzione disponibile automaticamente in ogni installazione WordPress.
Le Application Passwords hanno uno scopo diverso: sono credenziali revocabili per applicazioni, script, REST API e, se attivo, XML-RPC. Non sono password da usare per il login interattivo nel browser. Rivedi e revoca quelle non più associate a integrazioni necessarie.
4. Difendi il login senza bloccare utenti, integrazioni e area riservata
Gli attacchi brute force tentano automaticamente molte combinazioni di credenziali. Anche se non hanno successo, possono consumare risorse. La risposta più solida combina più livelli, invece di affidarsi a un cambio dell’URL di accesso.
Le difese da combinare
- Password uniche e 2FA per gli amministratori.
- Limitazione dei tentativi o rate limiting sul login.
- Challenge o CAPTCHA, quando appropriati.
- WAF dell’hosting, CDN o servizio dedicato per filtrare traffico automatizzato.
- Notifiche e controllo dei login anomali.
Il rate limiting non ha soglie valide per tutti. Una regola deve considerare traffico normale, utenti legittimi e integrazioni. Strumenti come Cloudflare consentono di definire endpoint, soglia, finestra temporale, azione e durata della mitigazione; imposta valori dopo aver osservato il comportamento reale del sito.
XML-RPC, wp-admin e URL di login: cosa non bloccare alla cieca
XML-RPC può servire a Jetpack, app mobili o altri flussi. Se non è necessario, puoi disabilitarlo o proteggerlo; se è usato, è preferibile limitarlo e applicare rate limiting piuttosto che bloccarlo indiscriminatamente.
Restrizioni generalizzate su /wp-admin/ possono interferire anche con admin-ajax.php, webhook, checkout e aree riservate. Cambiare l’URL di login può ridurre scansioni banali e rumore nei log, ma è solo oscuramento: non sostituisce password robuste, 2FA e limiti ai tentativi.
Test dopo una regola WAF o un blocco
Dopo ogni modifica verifica almeno login amministratore e utente, recupero password, moduli, REST API, webhook, Jetpack o app mobili se usati, checkout e area riservata. La protezione anti-spam dei moduli è utile, ma affronta un problema diverso dal brute force sul login.
5. Prepara backup separati e soprattutto ripristinabili
Un backup utile include database e file necessari al sito: installazione, plugin, temi, upload e file di configurazione rilevanti. Una sola copia automatica conservata nell’account hosting non è una strategia sufficiente.
Come riferimento pratico, usa il modello 3-2-1: tre copie dei dati, su due supporti o ambienti diversi, con almeno una copia fuori sede.
La verifica in sei domande
- Il backup include database e file?
- Esiste una copia separata dall’hosting principale?
- Sono conservate più versioni storiche?
- Gli accessi al backup sono protetti e chi può cancellarlo è noto?
- Il ripristino è stato testato, preferibilmente in staging?
- Quanto tempo serve realisticamente per tornare online?
Frequenza e conservazione dipendono da quanto cambiano dati e contenuti. Un sito vetrina aggiornato saltuariamente ha esigenze diverse da un e-commerce che raccoglie ordini ogni giorno. Pianifica backup e retention in base alla perdita di dati che puoi accettare, non in base a una frequenza universale.
6. Hardening tecnico: controlli utili da applicare con prudenza
Alcune misure richiedono accesso all’hosting, conoscenza del server o supporto tecnico. Non applicarle come ricette universali.
HTTPS, editor di file e debug in produzione
Verifica che tutto il sito, inclusa l’area amministrativa, usi HTTPS. L’impostazione FORCE_SSL_ADMIN può essere utile, ma in presenza di reverse proxy o configurazioni particolari può provocare loop di redirect se impostata senza verifiche.
La costante DISALLOW_FILE_EDIT disabilita gli editor integrati di temi e plugin. Riduce l’impatto di un accesso abusivo alla bacheca, ma non protegge da un accesso al server tramite SFTP o pannello hosting. In produzione, inoltre, il debug non dovrebbe mostrare errori al pubblico e il file debug.log non dovrebbe essere esposto nella web root.
Permessi, wp-config.php e chiavi di sicurezza
I permessi devono rispettare il principio del minimo privilegio ed essere coerenti con proprietà dei file e configurazione dell’hosting. WordPress indica generalmente directory 755 o 750 e file 644 o 640, ma non esiste un comando universale valido per ogni server. Evita i permessi 777 e coinvolgi l’hosting o un tecnico se WordPress non riesce a scrivere file.
Le chiavi e i salt in wp-config.php possono essere rigenerati dopo una sospetta esposizione delle credenziali o un cambio di personale. L’operazione invalida le sessioni attive e richiede un nuovo login a tutti gli utenti.
Se usi WP-CLI, wp core verify-checksums consente di confrontare i file del core con i checksum di WordPress.org. Un risultato positivo non esclude malware in wp-content o file estranei al core.
7. Trasforma la checklist in una routine di manutenzione
Ogni settimana
- Controlla aggiornamenti disponibili o falliti.
- Verifica il completamento dell’ultimo backup.
- Esamina notifiche di login sospetti e messaggi tecnici rilevanti.
Ogni mese
- Rivedi amministratori, ruoli e utenti inattivi.
- Rimuovi plugin e temi non necessari.
- Controlla Salute del sito, versione PHP, WP-Cron e licenze premium.
- Prova a recuperare almeno un elemento non critico dal backup.
Ogni trimestre o prima di modifiche rilevanti
- Testa un ripristino in staging.
- Riesamina regole WAF, rate limiting, XML-RPC e integrazioni API.
- Verifica email di recupero password e notifiche amministrative.
- Controlla che checkout, moduli, webhook e aree riservate continuino a funzionare.
Se emergono segnali di compromissione, evita di limitarti a un aggiornamento o a una scansione superficiale: segui una procedura specifica per un WordPress hackerato, con contenimento e bonifica.
Per la maggior parte dei piccoli siti, backup testati, aggiornamenti governati, pochi amministratori, 2FA e protezione del login offrono più valore di una collezione di plugin di sicurezza. Gli approfondimenti su backup e ripristino, staging, WAF/CDN, password manager e passkey aiutano poi a rendere solida ogni singola parte della checklist.









