
Checklist sicurezza WordPress: come controllare il sito e gestire un attacco
21 Settembre 2026 · Siti web
Per ridurre il rischio che il sito WordPress della tua azienda venga violato, verifica aggiornamenti, accessi, allarmi e possibilità di recupero. Puoi farlo anche senza essere un tecnico: chiedi al gestore prove datate delle attività e controlli sulle funzioni che usano i clienti. Se il sito è già compromesso, coinvolgi subito chi lo gestisce e il servizio di hosting per limitare i danni, conservare le prove e correggere la causa.
Che cosa rischia la tua azienda se il sito viene violato
Un sito WordPress violato può mostrare avvisi di pericolo, ospitare pagine spam o interrompere il percorso con cui un cliente ti contatta. La documentazione di Google sui problemi di sicurezza descrive sia gli avvisi legati al software dannoso sia le pagine aggiunte dagli attaccanti.
Per la tua azienda questo può significare visitatori che rinunciano a proseguire, contenuti estranei associati al nome aziendale e richieste commerciali che non arrivano. Anche un sito piccolo può essere raggiunto da attacchi automatici: avere poco traffico non lo mette al riparo.
Può essere coinvolta anche la posta. Se il sito compromesso invia spam, l’indirizzo IP del server di invio può finire in una lista di blocco; la posta aziendale può risentirne quando condivide quello stesso IP. È una possibilità descritta nella guida WordPress per i siti violati, non una conseguenza automatica per tutte le email del dominio.
Se il sito conserva richieste, dati personali o disegni tecnici, occorre verificare anche se siano stati consultati o sottratti. La presenza di un attacco, da sola, non dimostra che questo sia accaduto. Allo stesso modo, un periodo senza richieste può dipendere da un modulo guasto: è un segnale da controllare, non una prova di intrusione.
Il controllo comprende anche hosting, email e fornitori
La sicurezza di WordPress dipende dalla manutenzione dell’intero ambiente che permette di pubblicare, modificare e recuperare il sito. Il controllo deve quindi partire da un elenco dei servizi e delle persone che possono intervenire.
Chiedi un inventario datato con i relativi responsabili. Deve comprendere il dominio, cioè l’indirizzo del sito; l’hosting, che lo ospita; i DNS, che indirizzano il dominio verso i servizi corretti; le email usate per recuperare gli accessi. Il gestore deve censire anche WordPress, componenti aggiuntivi, vecchi sottodomini, copie di prova e collegamenti con gestionali o altri sistemi.
Esempio. WordPress è aggiornato, ma il pannello hosting usa una password condivisa e viene compromessa l’email che permette di recuperarla. Un attaccante può tentare di reimpostare l’accesso al pannello e intervenire sul sito senza passare dal normale ingresso di WordPress.
Per questo la tua azienda deve sapere chi controlla gli account principali e come recuperarli. Gli accessi di un fornitore cessato vanno verificati su tutti i servizi coinvolti, non soltanto dentro WordPress.
Come aggiornare WordPress senza interrompere le richieste
Tieni aggiornati WordPress, i componenti che aggiungono funzioni, chiamati plugin, e i temi che gestiscono l’aspetto del sito. Il fornitore deve seguire anche PHP, il software su cui funziona WordPress, scegliendo una versione compatibile che riceva ancora correzioni di sicurezza.
Il rapporto Patchstack 2026 attribuisce ai plugin il 91% delle nuove vulnerabilità censite nel 2025. Anche il rapporto Wordfence sui dati 2024 colloca nei plugin la maggior parte delle vulnerabilità registrate. Questi dati giustificano l’attenzione ai componenti installati; non indicano la percentuale di siti violati o le cause di tutte le intrusioni.
Usa componenti provenienti da fonti affidabili e mantieni disponibili gli aggiornamenti dei prodotti a pagamento. Elimina quelli inutili. Se un prodotto è abbandonato o presenta una falla senza correzione, chiedi al gestore se vada disattivato o sostituito.
Prima di un intervento serve una copia di sicurezza. Gli aggiornamenti che possono compromettere funzioni importanti vanno provati su una copia protetta del sito, chiamata ambiente di prova o staging. Il gestore deve poter tornare alla situazione precedente se qualcosa non funziona e verificare le funzioni anche dopo la pubblicazione. Anche gli aggiornamenti automatici richiedono un controllo degli esiti.
Esempio. Sulla copia di prova si invia un disegno dal modulo di richiesta e si controlla che arrivi alla casella predisposta per il test. Dopo l’aggiornamento del sito pubblico si ripete l’invio, verificando messaggio, allegato e destinatario: aprire la pagina iniziale non dimostra che il percorso funzioni.
Anche la copia di prova va protetta. Deve avere accessi limitati, credenziali diverse e solo i dati necessari ai test. Gli invii devono essere indirizzati a caselle di prova, senza mandare messaggi ai clienti o attivare operazioni reali nei sistemi collegati; la copia va eliminata quando non serve più.

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.
Come gestire gli accessi e revocare quelli dei fornitori
Ogni persona deve usare un account riconoscibile, una password unica e soltanto i permessi necessari al proprio lavoro. Chi modifica testi, per esempio, normalmente non ha bisogno di poter installare plugin o creare altri amministratori.
Gli accessi con poteri elevati devono essere protetti da un secondo controllo oltre alla password, per esempio una conferma tramite un’app. È l’autenticazione a due fattori, spesso indicata come 2FA o doppia verifica. Chiedila anche per hosting, gestione del dominio ed email di recupero, insieme alla protezione dai tentativi ripetuti di accesso.
Esempio. Al termine di un incarico viene revocato l’account personale del collaboratore su WordPress, hosting e servizi collegati. I colleghi continuano a usare i propri account: l’esclusione di una persona non richiede di cambiare la password di tutti.
Anche i collegamenti automatici con gestionali e altri servizi devono usare credenziali proprie, custodite in modo protetto e revocabili separatamente. Il gestore deve sapere quali collegamenti dipendono da ciascuna credenziale, così da rimuovere un accesso senza interrompere funzioni estranee. Questi principi di accesso limitato rientrano nelle indicazioni ufficiali per rafforzare la sicurezza di WordPress.
Quali protezioni tecniche chiedere al gestore
Chiedi al gestore di verificare la protezione delle connessioni, dei file riservati e dei contenuti ricevuti dall’esterno. Sono controlli tecnici che puoi includere nella verifica della gestione, senza modificare personalmente il server.
Come proteggere connessioni, file e allegati
Il sito deve usare HTTPS con un certificato valido, così da cifrare la comunicazione con il visitatore. Anche i trasferimenti amministrativi devono essere cifrati e i dispositivi di chi gestisce il sito devono essere aggiornati. Il lucchetto nel browser riguarda la connessione: non dimostra che plugin, account e copie di sicurezza siano gestiti correttamente.
Il tecnico deve limitare chi può leggere o modificare i file e accedere all’archivio dei dati, chiamato database. Configurazioni, chiavi segrete, archivi, backup e registrazioni diagnostiche non devono essere raggiungibili pubblicamente. Anche gli errori tecnici dettagliati devono restare riservati al gestore.
Per i moduli con allegati servono controlli sui tipi di file, sulle dimensioni e sul contenuto ricevuto. L’archivio deve impedire che un file caricato venga eseguito come programma. Il codice deve inoltre controllare i dati in ingresso, separarli dai comandi destinati al database e impedire che contenuti inseriti da estranei diventino istruzioni eseguibili nelle pagine.
Le istruzioni di sicurezza inviate al browser, chiamate intestazioni di sicurezza, vanno configurate verificando la compatibilità con il sito. Lo stesso criterio vale per le interfacce che collegano WordPress ad altri servizi, spesso chiamate API: il tecnico deve capire quali siano necessarie prima di limitarle, per evitare di bloccare moduli o integrazioni utili.
Quando serve un firewall applicativo o WAF
Un firewall applicativo, o WAF, esamina le richieste dirette al sito e può bloccare quelle riconosciute come pericolose. Aggiunge un livello di protezione agli aggiornamenti e alla gestione degli accessi; le sue regole devono essere controllate per evitare che fermino anche richieste legittime.
Per una vetrina senza moduli né aree riservate, un WAF dedicato e una sorveglianza umana continua non sono automaticamente necessari. La scelta dipende dalle funzioni esposte, dalle conseguenze di un’interruzione e dalle protezioni già offerte dall’hosting. Restano necessari manutenzione, allarmi automatici e possibilità di recupero.
Chi deve ricevere gli allarmi di sicurezza
Ogni allarme deve arrivare a una persona incaricata di valutarlo, con un sostituto e un canale di contatto concordato. Chiedi quali urgenze sono coperte, in quali orari e chi può intervenire: un avviso inviato a una casella non letta serve poco.
Le registrazioni degli eventi, chiamate log, aiutano a ricostruire accessi, modifiche ed errori. Il gestore deve combinarle con controlli sui componenti vulnerabili, scansioni alla ricerca di software dannoso e verifiche delle modifiche ai file. I risultati devono essere interpretati, non soltanto raccolti.
Fra i segnali da valutare ci sono nuovi amministratori, file modificati senza motivo, aggiornamenti o backup falliti e invii email anomali. Vanno seguite anche variazioni inattese dei DNS, scadenze dei certificati, errori e indisponibilità. Le segnalazioni di sicurezza di Google Search Console devono avere un destinatario preciso.
Serve inoltre un controllo dall’esterno, per sapere se il sito risponde ai visitatori. La documentazione WordPress sul monitoraggio distingue questi controlli dall’osservazione interna. Per le funzioni commerciali occorre aggiungere una prova del percorso completo, fino alla consegna della richiesta e degli allegati.
Come verificare che il backup permetta di recuperare il sito
Un backup deve comprendere file e database coerenti tra loro, essere conservato separatamente dal sito ed essere stato ripristinato in prova. Una notifica con scritto “backup completato” non dimostra che il recupero riesca.
Chiedi anche chi può cancellare le copie. Conservarle su un altro servizio aiuta poco se lo stesso account compromesso può eliminare sia il sito sia i backup. Le copie devono essere protette e accessibili attraverso credenziali adeguatamente separate.
Conservare più versioni permette di cercare una situazione precedente a un problema scoperto tardi. Frequenza delle copie e durata della conservazione vanno scelte in base ai dati che puoi permetterti di perdere e al tempo di interruzione sostenibile.
La prova di ripristino deve avere una data, un esito e una verifica delle funzioni. Chiedi al gestore se il recupero sia possibile anche perdendo l’hosting abituale e quale tempo di ripristino preveda nelle condizioni concordate.
Checklist sicurezza WordPress: quali prove chiedere al gestore
Puoi verificare la gestione chiedendo riscontri datati per ciascuna attività. Usa questa tabella durante un confronto con il fornitore: serve a distinguere ciò che è stato verificato da ciò che resta da fare.
| Domanda da fare | Prova da chiedere |
|---|---|
| Che cosa compone il sito e chi lo segue? | Inventario aggiornato di componenti e servizi, con versioni e responsabili. |
| Quali aggiornamenti sono stati fatti e quali problemi restano? | Registro degli interventi, problemi noti ancora aperti e decisioni sui componenti senza correzione. |
| Chi può entrare e con quali poteri? | Elenco degli account personali, relativi ruoli e conferma della doppia verifica sugli accessi privilegiati. |
| Gli accessi dei collaboratori cessati sono stati chiusi? | Revoca verificata su WordPress e servizi collegati, comprese le credenziali delle integrazioni. |
| Come avete controllato l’ultimo aggiornamento importante? | Esito dei test, possibilità di tornare indietro e prova di ricezione di una richiesta con allegato sul sito pubblico. |
| Chi riceve gli allarmi e chi interviene? | Esempio di avviso, destinatario, sostituto, contatti e orari di copertura concordati. |
| Il backup si può recuperare anche senza l’hosting abituale? | Posizione e protezione delle copie, data ed esito di un ripristino completo. |
| Che cosa succede se il sito viene violato? | Procedura breve con contatti, conservazione delle prove, contenimento, recupero e verifica della causa. |
Per ogni voce annota se è verificata, da completare, assente o non pertinente, spiegando il motivo e indicando la data. Una prova mancante significa che il controllo non è dimostrato; non dimostra che il sito sia già compromesso.
Ogni quanto ripetere i controlli di sicurezza
La frequenza dei controlli va concordata in base alle funzioni del sito e alle conseguenze di un problema. Il calendario ordinario deve prevedere un percorso separato per le urgenze.
Esempio di calendario: un riepilogo settimanale può verificare gli aggiornamenti eseguiti, gli esiti dei backup e la gestione degli allarmi. Un controllo mensile può riesaminare utenti, componenti inutili, moduli, dominio e certificati. A intervalli concordati si provano il ripristino e la procedura d’emergenza, aggiornando inventario e accessi dei fornitori. Gli allarmi urgenti vanno gestiti secondo gli accordi di intervento, senza aspettare il riepilogo.
Una vulnerabilità già sfruttata richiede una valutazione immediata. Per alcune falle molto bersagliate del 2025, il rapporto Patchstack colloca nell’ordine di poche ore il tempo al primo tentativo di attacco osservato dopo la divulgazione. Il dato riguarda il gruppo osservato dal fornitore e non stabilisce una scadenza sicura per il tuo sito.
Ripeti inoltre le verifiche quando cambia un fornitore, esce un collaboratore, viene aggiunto un modulo o si modifica l’infrastruttura. Questi cambiamenti possono rendere incompleto un controllo eseguito poco tempo prima.
Che cosa fare se il sito WordPress è stato violato
Se sospetti una violazione, attiva subito il gestore del sito e l’hosting attraverso i contatti di emergenza. La guida ufficiale WordPress per i siti compromessi raccomanda di documentare l’incidente, conservare una copia prima della pulizia e capire come sia entrato l’attaccante.
- Annota i segnali osservati. Conserva l’avviso ricevuto, gli indirizzi delle pagine coinvolte, l’ora della scoperta e le modifiche recenti. Segnala eventuali reindirizzamenti, nuovi amministratori o messaggi estranei.
- Fai contenere il danno e conservare le prove. Il tecnico valuta se limitare l’accesso al sito o disattivare le funzioni compromesse. Prima delle operazioni che cancellano informazioni, conserva log e una copia protetta dell’ambiente violato, distinta dalle copie destinate al recupero.
- Recupera il controllo degli accessi e fai correggere la causa. Vanno revocate le credenziali e le sessioni coinvolte, rimosso il punto d’ingresso e ripulito o ricostruito l’ambiente da fonti affidabili. Un backup può già contenere l’infezione: la sua data non basta a dichiararlo pulito.
- Verifica il ritorno al servizio. Prova pagine, moduli, allegati, notifiche e collegamenti con gli altri sistemi. Controlla nuovamente gli account e gli avvisi di sicurezza dopo la bonifica.
- Fai documentare la causa e gli interventi. Concorda i controlli per individuare eventuali ricomparse e valuta le comunicazioni necessarie. La chiusura deve comprendere una nuova verifica, oltre alla rimozione dei sintomi visibili.
Che cosa fare se sono coinvolti dati personali
La valutazione sui dati personali deve iniziare mentre si gestisce l’incidente, senza aspettare la fine della pulizia. Un attacco al sito e una violazione di dati personali richiedono verifiche distinte.
Secondo il Garante per la protezione dei dati personali, quando la notifica è dovuta, il titolare deve effettuarla senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza della violazione dei dati personali. La notifica non è richiesta se è improbabile un rischio per i diritti e le libertà delle persone. Le violazioni dei dati vanno comunque documentate; un rischio elevato può richiedere anche una comunicazione agli interessati, alle condizioni previste.
Quanto tempo serve per rimuovere un avviso di Google
Il riesame di sicurezza di Google può richiedere da alcuni giorni a qualche settimana, secondo la guida di Search Console. È il tempo dell’esame successivo alla correzione, distinto da quello necessario per ripulire il sito.
Prima di chiedere il riesame, il gestore deve risolvere tutti i problemi individuati, considerando che gli indirizzi segnalati possono essere solo un campione. Il ritorno online del sito e la rimozione dell’avviso sono quindi due verifiche separate.
Comincia dalle prove di gestione e dall’invio di una richiesta
Porta la checklist al gestore e chiedi un riscontro datato sulle attività essenziali. Parti dagli accessi ancora attivi, dai componenti con problemi noti, dal destinatario degli allarmi e dall’ultima prova di ripristino. Assegna un responsabile e una data alle attività mancanti.
Prova poi una richiesta dal sito, includendo un allegato rappresentativo di quelli che ricevi normalmente. Verifica che arrivi alla persona giusta e che possa essere lavorata dal commerciale. Questo controllo collega la sicurezza al funzionamento concreto del canale di contatto.
Ridurre le interruzioni può aiutarti a raccogliere più contatti tra le persone già interessate alla tua offerta. Ricevere richieste complete, con disegni e dati tecnici quando previsti, permette inoltre al commerciale di riconoscere i contatti più adatti e valutare come proseguire.
Fonti e riferimenti
- WordPress: Hardening WordPress, Monitoring e FAQ My site was hacked.
- Rapporti sulle vulnerabilità: Patchstack, State of WordPress Security in 2026, dati 2025; Wordfence, 2024 Annual WordPress Vulnerability and Threat Report, pubblicato nel 2025.
- Google Search Console: Report Problemi di sicurezza.
- Garante per la protezione dei dati personali: Violazioni di dati personali: che cosa fare.
Approfondisci il servizio: Hosting gestito.
