Checklist sicurezza WordPress: aggiornamenti, accessi, WAF, log e incidenti
21 Settembre 2026 · Siti web
Perché usare questa checklist
Questa checklist aiuta a verificare se un’installazione WordPress può essere aggiornata, sorvegliata e ripristinata senza affidarsi a configurazioni implicite. Non sostituisce vulnerability assessment o incident response specialistica, ma fa emergere componenti sconosciuti, accessi deboli e procedure di recupero mai provate.
Inventariare ciò che deve essere protetto
Core, temi, plugin, utenti, hosting, DNS, CDN, email, API e integrazioni devono avere owner, versione e stato.
Ridurre componenti e privilegi
Software inutilizzato, account condivisi e permessi eccessivi aumentano rischio e rendono difficile attribuzione e revoca.
Governare aggiornamenti e modifiche
Aggiornamenti, staging, backup, test e rollback devono essere proporzionati alla criticità. Le modifiche dirette in produzione vanno limitate.
Integrare protezioni e osservabilità
HTTPS, WAF, configurazione file, logging, alert e monitoraggio svolgono funzioni diverse. Nessuno sostituisce manutenzione e risposta.
Preparare incident response
Contenimento, evidenze, pulizia, rotazione credenziali, restore, comunicazione e post-mortem devono essere definiti e provati.
Checklist operativa
| Area | Controllo | Evidenza richiesta | Priorità |
|---|---|---|---|
| Inventario | Core, plugin, temi, utenti e integrazioni hanno owner e versione? | Asset inventory | Alta |
| Aggiornamenti | Esiste una policy con priorità, test e rollback? | Update policy | Alta |
| Componenti | Plugin e temi inutili, duplicati o abbandonati sono rimossi? | Component audit | Alta |
| Accessi | Account individuali, MFA e revoca sono applicati? | Access review | Alta |
| Ruoli | Privilegi seguono least privilege e necessità reale? | Role audit | Alta |
| File/config | Permessi e wp-config.php sono protetti e documentati? | Configuration review | Alta |
| Codice | Custom code usa validazione, sanitizzazione ed escaping? | Code review | Alta |
| WAF/CDN | Regole e responsabilità sono definite e monitorate? | WAF configuration | Media |
| HTTPS | Certificati, redirect e contenuti misti sono controllati? | HTTPS audit | Alta |
| Backup | File/database, offsite, retention e restore sono verificati? | Backup/restore report | Alta |
| Log/alert | Eventi utili sono conservati e gli alert hanno owner? | Monitoring plan | Alta |
| Incidenti | Runbook, contatti, prove e post-mortem sono disponibili? | Incident response test | Alta |
Come compilare la checklist
Un controllo WordPress è “conforme” solo se la protezione dichiarata si riscontra nell’installazione o in una prova recente, come un restore completato o una revoca verificata. “Parziale” segnala che la misura copre solo alcuni siti, account o componenti; “non conforme” richiede una correzione; “non applicabile” va usato soltanto quando l’asset esaminato non presenta quella funzione.
| Esito | Significato | Azione |
|---|---|---|
| Conforme | Regola applicata, provata e assegnata. | Mantenere e fissare la revisione. |
| Parziale | Pratica esistente ma incompleta o non misurabile. | Definire lacuna, owner e scadenza. |
| Non conforme | Controllo assente o problema osservato. | Aprire backlog e gestire dipendenze. |
| N/A | Controllo estraneo al perimetro. | Documentare la motivazione. |
Controlli bloccanti
Inventario
Core, plugin, temi, utenti e integrazioni hanno owner e versione? L’evidenza minima è “Asset inventory”. Il controllo è bloccante quando la sua assenza rende inaffidabili dati, decisioni o attività successive. Deve avere un owner e un criterio di chiusura.
Aggiornamenti
Esiste una policy con priorità, test e rollback? L’evidenza minima è “Update policy”. Il controllo è bloccante quando la sua assenza rende inaffidabili dati, decisioni o attività successive. Deve avere un owner e un criterio di chiusura.
Componenti
Plugin e temi inutili, duplicati o abbandonati sono rimossi? L’evidenza minima è “Component audit”. Il controllo è bloccante quando la sua assenza rende inaffidabili dati, decisioni o attività successive. Deve avere un owner e un criterio di chiusura.
Accessi
Account individuali, MFA e revoca sono applicati? L’evidenza minima è “Access review”. Il controllo è bloccante quando la sua assenza rende inaffidabili dati, decisioni o attività successive. Deve avere un owner e un criterio di chiusura.
Ruoli
Privilegi seguono least privilege e necessità reale? L’evidenza minima è “Role audit”. Il controllo è bloccante quando la sua assenza rende inaffidabili dati, decisioni o attività successive. Deve avere un owner e un criterio di chiusura.
File/config
Permessi e wp-config.php sono protetti e documentati? L’evidenza minima è “Configuration review”. Il controllo è bloccante quando la sua assenza rende inaffidabili dati, decisioni o attività successive. Deve avere un owner e un criterio di chiusura.
Output obbligatori
- Asset e access inventory
- Update/component policy
- Configuration/WAF/logging audit
- Backup e restore evidence
- Incident response runbook e test
Le anomalie rilevate devono diventare interventi tecnici ordinati per esposizione e dipendenze: rimuovere un plugin abbandonato, separare i backup o revocare un amministratore richiedono verifiche diverse. La voce può essere chiusa solo dopo aver ripetuto il controllo sull’ambiente interessato, non quando la modifica è stata semplicemente dichiarata.
Scenario applicativo
Il sito usa molti plugin, account amministratore condivisi e backup nello stesso hosting. Dopo un incidente viene ripristinata una copia senza correggere la vulnerabilità.
La checklist riduce componenti e privilegi, separa copie, attiva log e WAF governati e include analisi della causa e rotazione delle credenziali.
Errori da evitare
- Installare più plugin di sicurezza senza strategia.
- Usare admin condivisi.
- Aggiornare senza test o backup.
- Conservare copie nello stesso scenario di guasto.
- Considerare HTTPS sufficiente.
- Ripristinare senza eliminare la causa.
Domande frequenti
WordPress è insicuro per natura?
Richiede manutenzione e configurazione come ogni piattaforma; molti incidenti dipendono da componenti, credenziali e pratiche deboli.
Serve un WAF?
Può ridurre alcuni rischi e migliorare osservabilità, ma non sostituisce aggiornamenti, accessi e backup.
Quanto spesso fare un audit?
Controlli essenziali continui e revisioni approfondite periodiche, oltre che dopo cambi e incidenti.
Approfondisci il servizio: Hosting gestito.