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.
La mappa raccoglie i controlli da collegare alle prove tecniche della checklist.
Scarica l’infografica (PNG ad alta risoluzione)
Incorpora l’infografica nel tuo sito
Puoi ripubblicare l’infografica usando questo codice, con il collegamento all’articolo originale.
Inventariare ciò che deve essere protetto
L’inventario deve indicare chi segue il sito e i servizi collegati, quali componenti sono installati e se sono aggiornati. Deve comprendere gli utenti autorizzati e i collegamenti con gli strumenti aziendali, così chi interviene sa a chi rivolgersi e che cosa potrebbe risentire di una modifica.
Ridurre componenti e privilegi
Software inutilizzato, account condivisi e permessi eccessivi aumentano rischio e rendono difficile attribuzione e revoca.
Governare aggiornamenti e modifiche
Prima di aggiornare il sito di un’officina, una copia di prova permette di controllare che il modulo riceva ancora i disegni allegati. Serve una copia di sicurezza utilizzabile per tornare alla versione precedente in caso di problemi. Le prove devono coprire le funzioni da cui dipendono le richieste commerciali.
Integrare protezioni e osservabilità
Sul sito di un distributore, un WAF filtra le richieste web secondo regole di protezione; quelle regole vanno provate per evitare di bloccare gli invii validi del modulo. I log, le registrazioni degli eventi, aiutano il tecnico a ricostruire un errore o un accesso sospetto. Chi riceve un avviso deve sapere quando intervenire e come contattare il responsabile del sito.
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
Un costruttore di macchine che affida le schede a un collaboratore esterno deve potergli revocare l’accesso senza cambiare le credenziali di tutti. Ogni persona usa un account proprio. Con la MFA l’accesso richiede una seconda conferma oltre alla password. La prova del controllo comprende la verifica che un account revocato non possa più entrare.
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.
Una manutenzione verificata aiuta a mantenere disponibili le schede e i moduli da cui arrivano le richieste. Quando si verifica un guasto, il responsabile può attivare un recupero già provato e controllare che i contatti riprendano ad arrivare. Il commerciale può seguire i clienti con meno interruzioni dovute al sito.
Approfondisci il servizio: Hosting gestito.