La maggior parte degli attacchi riusciti a siti WordPress non passa da vulnerabilità tecniche sofisticate. Passa da una password debole su un account che nessuno ricordava di avere ancora, da un ex collaboratore che ha ancora accesso alla dashboard, da un amministratore con lo stesso nickname “admin” di default che usa da dieci anni.

La gestione degli accessi è l’aspetto della sicurezza WordPress più trascurato, proprio perché non richiede competenza tecnica avanzata: richiede processo e disciplina. Su siti con un solo utente il problema è contenuto. Su siti con più redattori, più figure che accedono al backend, clienti che hanno ricevuto credenziali nel tempo, il rischio si moltiplica in modo proporzionale al numero di account attivi.

Noi di Blurr gestiamo in manutenzione decine di siti per le agenzie partner e la verifica degli accessi è una delle prime cose che facciamo quando prendiamo in carico un sito esistente. Quello che troviamo quasi sempre è una storia di account accumulati nel tempo, con ruoli spesso sovradimensionati rispetto alle necessità reali.

Il caso che non si dimentica

Un’agenzia di Roma ci ha passato in gestione un sito editoriale con sei redattori attivi e una sezione riservata agli abbonati. Facendo l’audit iniziale degli utenti abbiamo trovato ventitré account con ruolo Editor o superiore. Ventitré. Il cliente ne riconosceva undici.

Gli altri dodici erano collaboratori passati, agenzie precedenti, persone che avevano avuto accesso per ragioni varie e su cui nessuno aveva mai fatto pulizia. Uno di quegli account, con ruolo Administrator, aveva una password di otto caratteri impostata nel 2019 e non cambiata da allora.

Quel sito non era stato compromesso, per fortuna. Ma era esposto in modo che rendeva la compromissione solo una questione di tempo. La pulizia ha richiesto meno di un’ora. L’esposizione era durata anni.

Ruoli WordPress: cosa può fare ciascuno e perché conta

WordPress ha cinque ruoli predefiniti con permessi progressivi: Subscriber, Contributor, Author, Editor, Administrator. Il problema più comune che vediamo non è l’assenza di ruoli, ma l’assegnazione automatica di ruoli troppo alti perché è “più comodo”.

Il redattore che deve solo pubblicare post non ha bisogno del ruolo Editor, che permette di modificare i post degli altri utenti e gestire i commenti. L’Editor non ha bisogno di essere Administrator solo perché ogni tanto ha bisogno di installare un plugin: quella è una operazione che l’agenzia o il partner tecnico fanno su richiesta, non una ragione per elevare i permessi in modo permanente.

La regola che applichiamo su tutti i siti che gestiamo è il principio del privilegio minimo: ogni utente ha il ruolo più basso che gli permette di svolgere le funzioni di cui ha bisogno. Non uno sopra.

Ruolo	Può pubblicare post	Può modificare post altrui	Può installare plugin	Può gestire utenti
Subscriber	No	No	No	No
Contributor	Solo bozze	No	No	No
Author	Sì (propri)	No	No	No
Editor	Sì	Sì	No	No
Administrator	Sì	Sì	Sì	Sì

Su siti con redattori freelance o collaboratori esterni, il ruolo Author è quasi sempre sufficiente. Il ruolo Editor va riservato a chi ha responsabilità editoriale reale sull’intero sito. Administrator va usato solo per chi gestisce tecnicamente la piattaforma, e anche in quel caso con un account nominale separato dall’account di lavoro quotidiano.

Autenticazione a due fattori: quando è obbligatoria e come si imposta

Il 2FA su WordPress non è ancora lo standard di fatto nel mercato italiano delle agenzie, anche se dovrebbe esserlo. La resistenza che incontriamo spesso è pratica: il cliente non vuole un passaggio aggiuntivo al login, i redattori si lamentano della complicazione. È una resistenza comprensibile ma sbagliata, e il modo più efficace per superarla è mostrare concretamente cosa può succedere senza.

La nostra posizione sui siti che gestiamo: il 2FA è obbligatorio per tutti gli account con ruolo Editor e superiore. Per i ruoli Author e Contributor lo raccomandiamo ma non lo imponiamo, a meno che il sito tratti dati sensibili o abbia sezioni riservate.

I plugin più affidabili per il 2FA su WordPress sono WP 2FA e Two Factor, entrambi gratuiti e ben mantenuti. Supportano autenticazione via app (Google Authenticator, Authy) e via email. L’app è più sicura dell’email: un account email compromesso non bypassa l’autenticazione. Su siti con molti utenti, WP 2FA permette di impostare il 2FA come obbligatorio per ruoli specifici, con un periodo di grazia configurabile per dare agli utenti esistenti il tempo di configurare il loro dispositivo.

La pulizia degli accessi: quando farla e come

Su un sito esistente che si prende in gestione, la pulizia degli accessi è il primo intervento. Non il terzo, non “quando c’è tempo”: il primo. Un sito con account non gestiti è un sito con una superficie di attacco che non si controlla.

Il processo che seguiamo: esportare la lista completa degli utenti con ruolo e data dell’ultimo accesso, inviare la lista al cliente chiedendo di confermare quali account sono ancora necessari, disabilitare o eliminare tutti gli account non confermati, cambiare le password di tutti gli account Administrator, abilitare il 2FA per Editor e Administrator.

La data dell’ultimo accesso è un dato prezioso. Un account Administrator che non accede da diciotto mesi è quasi certamente un account dimenticato. Uno che non accede da tre mesi su un sito editoriale attivo è sospetto. Uno che accede regolarmente è un utente reale.

Per i siti in manutenzione con Blurr, questa verifica fa parte del processo trimestrale di revisione della sicurezza, insieme al controllo dei log di accesso e alla verifica che non ci siano stati tentativi di brute force non bloccati. Se vuoi capire come funziona il monitoraggio della sicurezza nel tempo, l’articolo su cosa succede a un sito senza monitoraggio copre il tema nel dettaglio.

Username admin e URL di login: i due default da cambiare sempre

Due configurazioni di default di WordPress che aumentano inutilmente la superficie di attacco: l’username “admin” e l’URL di login /wp-admin.

L’username “admin” è il primo che qualsiasi script di brute force prova. Se l’account Administrator principale si chiama “admin”, metà del lavoro dell’attaccante è già fatto: deve solo indovinare la password. Cambiare lo username di un account esistente in WordPress non è possibile direttamente dalla dashboard, ma si fa facilmente dal database o creando un nuovo account con username diverso, trasferendo i contenuti e eliminando il vecchio.

L’URL /wp-admin è nota a chiunque. Cambiarlo con plugin come WPS Hide Login o attraverso configurazione del server non è una protezione sufficiente da sola, ma riduce significativamente il traffico automatizzato di bot che tentano accessi sulla URL standard. Su alcuni siti che gestiamo abbiamo visto cali del 90% nei tentativi di accesso dopo aver spostato l’URL di login su un percorso non standard.

Entrambe queste modifiche vanno fatte all’inizio, su ogni sito, prima ancora di preoccuparsi di plugin di sicurezza più sofisticati. Sono le fondamenta, non gli optional.

Come strutturare la consegna degli accessi al cliente

Quando si consegna un sito al cliente, la gestione degli accessi iniziali è un momento critico che spesso viene gestito in modo approssimativo: si manda username e password in chiaro via email, si imposta una password temporanea che il cliente non cambierà mai, si lascia al cliente la libertà di creare account aggiuntivi senza nessuna indicazione.

Il modo corretto prevede alcune scelte precise. La password iniziale dell’account Administrator del cliente deve essere robusta e generata casualmente, non una che il cliente sceglie lui durante il setup. Va trasmessa attraverso un canale sicuro, non in chiaro in un’email che resterà nella posta in arrivo per anni. E il cliente va informato esplicitamente che quella password va cambiata al primo accesso e che non deve essere condivisa.

Per i siti con più utenti, consegnare una procedura scritta su come aggiungere nuovi account, quale ruolo assegnare a quale figura e quando contattare l’agenzia per richieste che richiedono accesso Administrator è un servizio che quasi nessuna agenzia offre e che il cliente percepisce come valore aggiunto reale.

Se vuoi strutturare meglio questo processo sulla tua agenzia, e hai siti in gestione che non sai con certezza come siano configurati lato accessi, scrivici da blurr.it/contatti/. Facciamo un audit degli accessi come primo step prima di qualsiasi altro intervento.

Domande frequenti

Quanti account Administrator è normale avere su un sito WordPress?

In quasi tutti i casi, uno solo: quello dell’agenzia o del partner tecnico che gestisce il sito. Il cliente può avere un account Administrator per situazioni di emergenza, ma nella pratica quotidiana non ne ha bisogno. Più account Administrator significa più punti di accesso totale al sito, ognuno dei quali va protetto con la stessa cura. Se l’agenzia che ha sviluppato il sito ha lasciato il proprio account Administrator attivo senza che nessuno lo sappia, è un problema da risolvere subito.

Il 2FA rallenta significativamente l'esperienza di login per i redattori?

Il passaggio aggiuntivo richiede dieci secondi. L’app di autenticazione genera un codice ogni trenta secondi e inserirlo è più rapido di quanto sembri nella pratica quotidiana. Chi lavora ogni giorno sulla dashboard ci fa l’abitudine in una settimana. La resistenza iniziale è reale ma scompare rapidamente. Il modo migliore per gestirla è non presentare il 2FA come un’opzione ma come una procedura standard del sito, allo stesso modo in cui nessuno discute sull’obbligo della password.

Cosa fare se un collaboratore esterno ha ancora accesso dopo la fine del rapporto?

Disabilitare o eliminare l’account immediatamente, non appena si viene a conoscenza della situazione. Se l’account aveva ruolo Editor o superiore, cambiare anche le password degli altri account Administrator come misura precauzionale, poiché non è possibile sapere se l’accesso è stato usato per creare backdoor o modificare configurazioni. Verificare i log di accesso degli ultimi mesi se disponibili. Per i siti in manutenzione con Blurr, la segnalazione di un account da revocare viene gestita entro la giornata.

Conviene usare un plugin di sicurezza tipo Wordfence su tutti i siti?

Wordfence è efficace ma ha un costo in termini di risorse server: il suo firewall e il suo scanner consumano CPU e memoria in modo significativo, specialmente su hosting condivisi. Su hosting condivisi entry-level può peggiorare le performance più di quanto migliori la sicurezza. L’alternativa che preferiamo è gestire la sicurezza a livello di Cloudflare per le regole di accesso e i rate limit, e usare plugin leggeri per il solo monitoraggio dei log. La combinazione è più efficiente e non appesantisce il server.

È uno scenario che si presenta più spesso di quanto si ammetta nel settore. Il developer freelance che seguiva il sito di un cliente smette di rispondere. Non è malafede necessariamente: a volte è un problema personale, a volte ha trovato un lavoro fisso, a volte ha semplicemente deciso di sparire. Il problema non è la sua scomparsa: è che era l’unico con accesso all’hosting, al dominio, a Cloudflare, al pannello di amministrazione WordPress. Il cliente ti chiama perché il sito non funziona o perché deve fare una modifica urgente. E tu non puoi fare niente.

Questa situazione l’abbiamo gestita più volte, sia direttamente sia supportando agenzie partner che si trovavano in questa posizione. La cosa che accomuna quasi tutti i casi è la stessa: nessuno aveva pensato a separare gli accessi fin dall’inizio, perché in quel momento sembrava una complicazione inutile. Non lo era.

Questo articolo ha due parti. La prima è il protocollo da eseguire adesso se sei già in questa situazione. La seconda è il sistema da implementare subito dopo per non trovarti mai più in questa posizione.

Parte 1 — I primi 60 minuti: recuperare il controllo

La sequenza di azioni dipende da cosa il freelancer controllava. Nella maggior parte dei casi, i punti critici sono quattro: il dominio, l’hosting, Cloudflare e l’account WordPress amministratore.

Passo 1: Verifica cosa è ancora accessibile. Prima di fare qualsiasi altra cosa, mappa la situazione. Puoi accedere al backend WordPress? Riesci ad entrare nel pannello di hosting? Hai accesso al registrar del dominio? Hai accesso all’account Cloudflare? Per ogni punto di accesso, annota se hai le credenziali, se le credenziali sono intestate al cliente o al freelancer, e se c’è un metodo di recupero disponibile.

Passo 2: Recupera l’accesso al dominio. Il dominio è il punto più critico. Se il freelancer ha registrato il dominio a suo nome invece che a nome del cliente, il recupero è complicato e richiede procedure legali. Se il dominio è a nome del cliente ma le credenziali del registrar erano gestite dal freelancer, quasi tutti i registrar permettono il recupero tramite verifica dell’intestatario: il cliente può richiedere il recupero dell’accesso dimostrando di essere il proprietario legale del dominio con email aziendale o documenti.

Registrar come Aruba, Register.it e GoDaddy hanno procedure specifiche per questo scenario. Il tempo di recupero varia da poche ore a qualche giorno. Nel frattempo il dominio è operativo: non smette di funzionare perché hai perso l’accesso al pannello del registrar.

Passo 3: Recupera l’accesso all’hosting. Se l’account di hosting è intestato al cliente, il recupero segue la stessa procedura del registrar: verifica dell’intestatario tramite support ticket. Se l’account è intestato al freelancer, il provider di hosting non può darti accesso per ragioni legali, ma può nella maggior parte dei casi creare un backup del contenuto e consegnarlo al proprietario legale del dominio dietro documentazione. Contatta il supporto dell’hosting con la documentazione che dimostra che il cliente è il proprietario del sito.

Passo 4: Recupera l’accesso a WordPress. Se hai ancora accesso all’hosting, puoi resettare la password dell’amministratore WordPress direttamente dal database tramite phpMyAdmin o tramite WP-CLI. La query SQL per resettare la password di un utente amministratore è una procedura standard che non richiede accesso al backend WordPress.

Se non hai accesso all’hosting ma hai accesso FTP, puoi aggiungere un file PHP temporaneo alla root del sito che resetta la password dell’amministratore. Non è la soluzione più elegante ma funziona in emergenza.

Passo 5: Recupera l’accesso a Cloudflare. Questo è il punto più complesso. Se il freelancer aveva creato l’account Cloudflare a suo nome e non ha aggiunto il cliente come membro, il recupero richiede la procedura di dispute del dominio di Cloudflare. Il cliente deve dimostrare di essere il proprietario legale del dominio, dopodiché Cloudflare trasferisce il controllo della zona DNS.

Ci è capitato direttamente con un progetto che stavamo supportando per un’agenzia partner. Il developer precedente aveva configurato Cloudflare con il suo account personale e non aveva mai aggiunto nessun altro come amministratore. Quando è sparito, l’agenzia non poteva modificare i DNS, non poteva attivare protezioni, non poteva cambiare niente sull’infrastruttura. Abbiamo aperto un ticket di supporto con Cloudflare documentando la proprietà del dominio. Il processo ha richiesto quattro giorni lavorativi. Nel frattempo il sito era operativo ma completamente indifeso, e non potevamo modificare nessuna configurazione.

Passo 6: Cambia tutte le password immediatamente. Non appena recuperi l’accesso a ogni componente, cambia le credenziali. Tutte. Hosting, WordPress, Cloudflare, dominio, email collegata all’account. Anche se il freelancer non aveva intenzioni malevole, lasciare le sue credenziali attive è un rischio inutile.

Verifica anche i token API, le chiavi SSH e i webhook configurati: sono vettori di accesso meno visibili che spesso non vengono considerati durante il recupero delle credenziali standard.

Parte 2 — Come non trovarsi mai più in questa situazione

Il recupero è costoso in termini di tempo, stress e rapporto con il cliente. La prevenzione richiede cinque minuti in più all’inizio di ogni progetto.

Regola 1: Il dominio deve essere sempre intestato al cliente. Senza eccezioni. Il registrar, le credenziali di accesso, la email di recupero: tutto intestato al cliente o all’agenzia, mai al developer che segue il progetto. Se il cliente non vuole gestire il dominio da solo, l’agenzia può gestirlo per lui, ma deve essere l’agenzia il proprietario registrato, non il freelancer.

Regola 2: L’hosting deve avere accessi separati per ruolo. Il cliente deve avere un accesso con le sue credenziali. L’agenzia deve avere un accesso separato. Il developer freelance, se coinvolto, deve avere un accesso con permessi limitati a quello che serve per il suo lavoro specifico. La maggior parte degli hosting provider supporta account utente multipli con permessi diversi. Usarli dall’inizio è la prevenzione più efficace.

Regola 3: Cloudflare con accesso multi-utente. Cloudflare permette di aggiungere membri con ruoli diversi a ogni account zona. Il developer può avere accesso come membro con permessi limitati. Il cliente e l’agenzia devono avere accesso come amministratori. Configurarlo richiede tre minuti alla creazione del sito.

Regola 4: WordPress con ruoli separati. Il developer lavora con un account amministratore a suo nome. Il cliente ha il suo account amministratore separato. Noi di Blurr creiamo sempre almeno due account amministratori su ogni sito che sviluppiamo per le agenzie partner: uno operativo per il lavoro quotidiano e uno di backup con una email diversa. Se per qualsiasi motivo un account viene perso o compromesso, l’altro rimane disponibile.

Regola 5: Documenta tutto in un documento condiviso fin dal primo giorno. Un documento semplice con tutti gli accessi, le credenziali di recupero, i contatti dei provider: è il documento che evita il panico quando qualcosa va storto. Non deve essere elaborato: basta che esista e che sia aggiornato ogni volta che cambia qualcosa.

Regola 6: Il contratto con il freelancer deve includere la restituzione degli accessi. Una clausola contrattuale che obbliga il freelancer a restituire tutti gli accessi e le credenziali alla conclusione del rapporto di lavoro, con penale in caso di inadempienza. Non è una misura sufficiente da sola perché un freelancer sparito non risponde al contratto, ma è uno strumento utile se la situazione diventa una disputa legale.

Lavorare con Blurr come partner white label elimina strutturalmente questo rischio. Non siamo un freelancer singolo: siamo una struttura societaria con procedure di gestione degli accessi standardizzate su ogni progetto. Ogni sito che sviluppiamo mantiene una documentazione completa degli accessi che l’agenzia partner può richiedere in qualsiasi momento. Su blurr.it/contatti/ puoi prenotare una chiamata per capire come strutturiamo questa parte del processo. Per approfondire come gestiamo la sicurezza e il monitoraggio su ogni progetto, leggi cosa succede a un sito web senza monitoraggio. Per capire come strutturiamo il NDA e le clausole contrattuali nel rapporto con le agenzie partner, leggi l’articolo dedicato.

FAQ

Come si recupera l'accesso a un dominio se il freelancer è sparito?

Se il dominio è intestato al cliente, quasi tutti i registrar permettono il recupero tramite verifica dell’intestatario: il cliente dimostra di essere il proprietario legale tramite email aziendale o documenti e il registrar ripristina l’accesso. Se il dominio è intestato al freelancer, il recupero richiede procedure legali più complesse e potrebbe richiedere settimane. Per questo il dominio deve essere sempre intestato al cliente o all’agenzia, mai al developer che segue il progetto.

Come si recupera l'accesso a WordPress senza le credenziali dell'amministratore?

Tramite accesso diretto al database. Con phpMyAdmin o WP-CLI, è possibile resettare la password di qualsiasi utente amministratore WordPress modificando direttamente il record nella tabella wp_users. Richiede accesso all’hosting. Se non si ha accesso all’hosting, si può aggiungere un file PHP temporaneo alla root del sito tramite FTP per eseguire il reset. Entrambe le procedure sono standard e non distruttive per il sito.

Cosa fare se Cloudflare è configurato sull'account personale del freelancer?

La soluzione più rapida non passa dal supporto Cloudflare ma dal registrar del dominio. Se si ha accesso al registrar dove il dominio è registrato, si possono cambiare i nameserver da quelli di Cloudflare a qualsiasi altro DNS provider, oppure aggiungere il dominio a un nuovo account Cloudflare. Cloudflare segue il dominio, non l’account: chi controlla il registrar controlla i nameserver e quindi controlla quale account Cloudflare gestisce la zona DNS. Se non si ha accesso nemmeno al registrar, si apre un ticket con il supporto Cloudflare documentando la proprietà del dominio, ma i tempi e le procedure variano caso per caso senza un processo standardizzato. Nel frattempo il sito continua a funzionare normalmente: perdere l’accesso all’account Cloudflare non interrompe il servizio.

Come prevenire questo problema sui nuovi progetti?

Con cinque regole: dominio sempre intestato al cliente o all’agenzia, hosting con accessi separati per ruolo, Cloudflare con accesso multi-utente configurato dall’inizio, WordPress con almeno due account amministratori distinti, e un documento condiviso con tutti gli accessi aggiornato ad ogni modifica. Il contratto con il freelancer deve includere una clausola esplicita di restituzione degli accessi alla conclusione del rapporto.

Quando un sito di un cliente va giù per un attacco, hai circa quindici minuti per contenere il danno prima che il cliente lo scopra da solo e ti chiami in panico. Quello che fai in quei quindici minuti determina se l’incidente diventa un problema gestito o una crisi che danneggia il rapporto con il cliente. Non esiste improvvisazione in questa fase: o hai un protocollo pronto o perdi tempo prezioso a capire da dove iniziare.

Questo articolo è quel protocollo. È costruito sull’esperienza diretta di gestione di incidenti su siti WordPress in produzione, con le lezioni apprese da situazioni che non sono andate come avrebbero dovuto. Non è teoria sulla sicurezza informatica: è la sequenza di azioni concrete da eseguire nell’ordine giusto quando il problema è già in corso.

Prima di tutto: capire cosa sta succedendo

La distinzione più importante da fare nei primi minuti è quella tra un attacco DDoS e un’infezione o compromissione del sito. Sono problemi diversi che richiedono risposte diverse.

Un attacco DDoS (Distributed Denial of Service) non compromette il sito: lo sommerge di traffico fino a renderlo irraggiungibile. Il sito è tecnicamente intatto ma non risponde perché il server è sovraccarico. L’attacco può durare minuti o giorni.

Una compromissione del sito significa che qualcuno ha avuto accesso non autorizzato: ha installato malware, iniettato codice, creato backdoor o rubato dati. Il sito può sembrare funzionante ma è stato modificato. Questo richiede un’analisi forense prima di qualsiasi altra azione.

Un ransomware su hosting condiviso è più raro ma esiste: il server viene cifrato e l’accesso ai file bloccato. In questo caso il problema è dell’hosting provider, non del sito specifico, e la risposta è diversa.

I segnali che distinguono i tre scenari: se il sito è irraggiungibile ma i file sono intatti e i log mostrano volumi anomali di traffico, è DDoS. Se il sito è raggiungibile ma mostra contenuti strani, reindirizza su altri siti o Google mostra warning “questo sito potrebbe essere dannoso”, è una compromissione. Se non riesci ad accedere all’hosting e il provider non risponde normalmente, valuta il ransomware.

Fase 1 — I primi 15 minuti: isolamento

L’obiettivo di questa fase è fermare il danno attivo senza perdere le prove di cosa sta succedendo.

Attiva la modalità manutenzione o Under Attack Mode su Cloudflare. Se il sito usa Cloudflare, vai su Security → Settings e attiva “Under Attack Mode”. Questa modalità aggiunge un challenge JavaScript a ogni visitatore prima di mostrare il sito, bloccando la maggior parte del traffico automatizzato malevolo in pochi secondi. Il sito rimane raggiungibile per gli utenti umani ma con un ritardo di cinque secondi. È la prima azione da fare su qualsiasi attacco DDoS su sito con Cloudflare attivo.

Se il sito non usa Cloudflare, attiva la modalità manutenzione di WordPress tramite un plugin dedicato o inserendo manualmente un file .maintenance nella root del sito. Non è efficace contro il DDoS a livello di rete ma blocca le richieste a livello applicativo e mostra al visitatore umano un messaggio controllato invece di un errore.

Identifica il tipo di attacco nei log. Accedi al pannello di hosting e cerca i log di accesso di Apache o Nginx degli ultimi trenta minuti. Cerca pattern anomali: migliaia di richieste allo stesso URL (tipicamente /wp-login.php, /xmlrpc.php o la homepage), tutte con lo stesso user-agent o da range IP simili. Questo è un attacco a livello applicativo. Se il server è irraggiungibile completamente, incluso il pannello di hosting, è un attacco a livello di rete che richiede l’intervento del provider.

Blocca le IP o i range di IP malevoli. Se il pattern mostra richieste massive da un range IP identificabile, blocca quel range nel firewall di Cloudflare o nel file .htaccess. Non è una soluzione definitiva ma riduce immediatamente il carico sul server. Una query semplice nei log di Nginx o Apache mostra le IP con più richieste negli ultimi trenta minuti: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20.

Scatta uno screenshot dello stato attuale. Prima di fare qualsiasi altra modifica, documenta tutto: screenshot della dashboard Cloudflare con i volumi di traffico anomali, screenshot dei log con i pattern identificati, stato del sito in quel momento. Se in futuro ci sarà bisogno di una segnalazione alle autorità o di una disputa assicurativa, questa documentazione è fondamentale.

Fase 2 — Da 15 a 30 minuti: analisi e contenimento

Con il danno immediato fermato o rallentato, si passa all’analisi per capire la portata reale dell’incidente.

Verifica se si tratta di DDoS o compromissione. Accedi al backend di WordPress se possibile e controlla: ci sono utenti amministratori che non dovrebbero esserci? Ci sono file PHP nella cartella uploads che non hai mai caricato? Ci sono plugin o temi attivati che non riconosci? Se sì, il sito è stato compromesso e il DDoS potrebbe essere una distrazione o una conseguenza del malware.

Esegui un primo scan di sicurezza. Se Wordfence è installato, esegui un scan immediato. Wordfence identifica i file modificati rispetto alla versione originale di WordPress e dei plugin e segnala i file sospetti. Sucuri Scanner e MalCare sono alternative valide se Wordfence non è installato. Non aspettare che lo scan sia completo per procedere: avvialo e vai avanti.

Verifica i backup disponibili. Identifica l’ultimo backup pulito del sito: quando è stato fatto, dove è conservato, come si ripristina. Se il sito è stato compromesso, potresti aver bisogno di un ripristino completo da un punto precedente all’infezione. Sapere dove si trovano i backup e quanto sono recenti in questa fase ti permette di valutare le opzioni senza perdere tempo dopo.

Registra tutto in un documento condiviso. Apri un documento e inizia a registrare: orario di scoperta del problema, azioni eseguite con timestamp, risultati dei check, stato del sito. Questo documento serve per la comunicazione interna al team, per la comunicazione al cliente e per l’analisi post-incidente.

Fase 3 — Da 30 a 60 minuti: comunicazione e risoluzione

Con la situazione contenuta e documentata, si passa alla comunicazione con il cliente e alla risoluzione definitiva.

Contatta il cliente prima che lo scopra da solo. Questa è la parte che fa la differenza tra un cliente che si fida di te e uno che non lo farà mai più. Non aspettare di aver risolto tutto per comunicare. Contattalo adesso, con le informazioni che hai: “Abbiamo rilevato un’anomalia sul tuo sito e stiamo intervenendo. Il sito è temporaneamente in modalità manutenzione per proteggere i dati. Ti aggiornerò tra trenta minuti con lo stato completo.”

Non usare la parola “attacco” se non sei ancora sicuro. Non fare promesse sui tempi di ripristino che potresti non rispettare. Sii specifico su cosa stai facendo e quando darai il prossimo aggiornamento.

Risolvi il problema identificato. Se è DDoS puro: con Cloudflare in Under Attack Mode il sito è già protetto. Valuta se alzare ulteriormente le protezioni con regole WAF specifiche per bloccare il traffico anomalo in modo più granulare. Contatta il provider di hosting per segnalare l’attacco e richiedere supporto a livello di rete se il volume supera quello che Cloudflare riesce a gestire.

Se è compromissione: non riavviare il sito prima di aver rimosso il malware. Ripristina da un backup pulito se il malware è esteso e difficile da identificare completamente. Se il backup è anch’esso compromesso, la rimozione manuale richiede un developer con esperienza in sicurezza WordPress.

Fai un report post-incidente entro 24 ore. Dopo la risoluzione, prepara un documento sintetico per il cliente: cosa è successo, come è stato gestito, cosa è stato fatto per prevenire che si ripeta. Non è un mea culpa: è la dimostrazione che hai il controllo della situazione e che stai proteggendo il suo sito in modo professionale. Le agenzie che fanno questo report costruiscono una fiducia che vale molto più del problema che hanno gestito.

Il caso che ci ha insegnato il valore del protocollo

Un’agenzia con cui lavoriamo gestiva l’ecommerce di un’azienda di abbigliamento durante il Black Friday. Alle 10:40 di venerdì mattina il sito è andato giù per un attacco DDoS a livello applicativo: migliaia di richieste al minuto verso /wp-login.php da centinaia di IP diversi. Il server dell’hosting era in ginocchio.

Il titolare dell’agenzia ci ha subito contattati e abbiamo subito attivato il protocollo. Alle 10:49 avevamo attivato Under Attack Mode su Cloudflare. Alle 10:52 avevamo identificato il pattern nei log e bloccato i range IP principali. Alle 10:55 avevamo inviato un messaggio al titolare dell’agenzia che ha subito contattato così il cliente: “Stiamo gestendo un picco anomalo di traffico. Il sito è temporaneamente rallentato ma funzionante. Ti aggiorno alle 11:30.”

Alle 11:23 il sito era completamente operativo. Il cliente aveva perso circa 35 minuti di traffico ridotto ma non c’era stato nessun downtime completo. La comunicazione proattiva aveva trasformato una potenziale crisi in una dimostrazione di competenza. Il cliente ha rinnovato il contratto di manutenzione aumentando il canone mensile.

La differenza tra quel risultato e uno scenario catastrofico era il protocollo pronto. Non la bravura nell’improvvisare.

Quando serve un supporto esterno per gestire un attacco

Non tutte le agenzie o le aziende hanno al proprio interno le competenze e le risorse necessarie per intervenire rapidamente quando un sito viene compromesso o finisce sotto attacco. È una situazione più comune di quanto si pensi: spesso veniamo contattati da agenzie che gestiscono decine di siti WordPress per conto dei propri clienti e che si trovano ad affrontare un’emergenza fuori dall’ordinario, oppure da aziende e professionisti che scoprono un problema quando il sito è già offline o segnalato come pericoloso dai motori di ricerca.

In questi casi il fattore più importante non è soltanto risolvere il problema tecnico, ma farlo nel minor tempo possibile limitando il danno economico e reputazionale. Un sito ecommerce fermo durante una campagna marketing, un portale aziendale irraggiungibile o un sito infettato da malware possono generare conseguenze significative già nelle prime ore.

Per questo motivo interveniamo sia in modalità emergenziale sia attraverso attività preventive di monitoraggio e manutenzione. Analizziamo l’origine dell’attacco, individuiamo eventuali vulnerabilità sfruttate, ripristiniamo il corretto funzionamento del sito e implementiamo le misure necessarie per ridurre il rischio che l’incidente si ripeta. Quando richiesto, supportiamo anche l’agenzia nella comunicazione con il cliente finale e nella preparazione della documentazione tecnica post-incidente.

Molti dei clienti che oggi seguiamo in modo continuativo ci hanno inizialmente contattato proprio durante una situazione critica. La differenza tra un disservizio temporaneo e una crisi che compromette il rapporto con il cliente spesso dipende dalla rapidità con cui viene attivata una procedura di risposta efficace.

Se gestisci siti WordPress per conto di clienti o hai bisogno di un supporto specialistico per un sito sotto attacco, puoi contattarci per una valutazione immediata della situazione e delle possibili azioni da intraprendere.

Come prevenire che si ripeta

Un attacco gestito bene è anche un’opportunità per strutturare meglio la sicurezza del sito per il futuro.

Le misure che implementiamo sistematicamente dopo ogni incidente: Cloudflare attivo con regole WAF per bloccare le richieste massive a /wp-login.php e /xmlrpc.php, autenticazione a due fattori su tutti gli account amministratori WordPress, accesso al backend limitato per IP quando possibile, backup giornalieri automatici conservati fuori dall’hosting del sito, monitoraggio uptime con alerting immediato via SMS.

Noi di Blurr includiamo tutte queste misure nei siti che sviluppiamo e manteniamo per le agenzie partner. Non come servizio aggiuntivo: come parte del processo standard di consegna. Su blurr.it/servizi/ trovi come strutturiamo la sicurezza su ogni progetto. Per approfondire cosa succede a un sito senza monitoraggio attivo, leggi cosa succede a un sito web senza monitoraggio: un caso reale. Per capire come strutturiamo i piani di manutenzione che includono la gestione degli incidenti, leggi l’articolo dedicato.

FAQ

Come capire se un sito WordPress è sotto attacco DDoS o è stato compromesso?

Se il sito è irraggiungibile ma i file sono intatti e i log mostrano volumi anomali di traffico da molti IP diversi, è quasi certamente un DDoS. Se il sito è raggiungibile ma mostra contenuti insoliti, reindirizza verso altri URL o Google mostra avvisi di sicurezza, è una compromissione. I due problemi possono coesistere: un sito compromesso può essere usato come origine di un DDoS verso altri siti.

Cosa fare immediatamente se il sito di un cliente viene attaccato?

Prima azione: attivare Under Attack Mode su Cloudflare se disponibile, o la modalità manutenzione di WordPress. Seconda: identificare il tipo di attacco nei log. Terza: bloccare i range IP malevoli identificati. Quarta: documentare tutto con timestamp. Quinta, e non meno importante: contattare il cliente con un aggiornamento proattivo prima che scopra il problema da solo. L’ordine di queste azioni determina il risultato dell’incidente.

Cloudflare Under Attack Mode blocca anche i visitatori normali?

Aggiunge un challenge JavaScript della durata di circa cinque secondi a ogni nuovo visitatore. Gli utenti umani superano il challenge automaticamente dopo pochi secondi. I bot automatici che non eseguono JavaScript vengono bloccati. Il sito rimane accessibile ma con un leggero ritardo. È una misura temporanea da disattivare non appena l’attacco è contenuto.

Quanto tempo ci vuole per ripristinare un sito WordPress dopo un attacco?

Dipende dalla tipologia. Un DDoS gestito con Cloudflare si contiene in meno di trenta minuti nella maggior parte dei casi. Una compromissione con malware richiede da due a otto ore per un’analisi e pulizia completa, o meno se si ripristina da un backup pulito recente. Un sito senza backup recente e con malware esteso può richiedere uno o due giorni di lavoro. È questo il motivo per cui i backup giornalieri automatici fuori dall’hosting non sono un’opzione: sono il prerequisito di qualsiasi piano di sicurezza sensato.

Il Rapporto CLUSIT 2026 ha fotografato una situazione che chi lavora nel settore web come noi percepisce ormai ogni giorno: nel 2025 gli attacchi informatici gravi contro organizzazioni italiane sono aumentati del 42% rispetto all’anno precedente, con 507 incidenti critici andati a buon fine. Il 43% degli attacchi colpisce le PMI, che sono spesso prive di presidio di sicurezza dedicato e rappresentano bersagli facili per chi cerca riscatti rapidi.

Ce ne siamo resi conto in modo diretto negli ultimi mesi: tra i siti WordPress che gestiamo per le agenzie partner, abbiamo intercettato un numero crescente di tentativi di accesso non autorizzato, plugin con vulnerabilità note non aggiornati e configurazioni di sicurezza incomplete che avrebbero potuto essere sfruttate. Non è allarmismo: è quello che i dati dicono e quello che vediamo concretamente.

Perché WordPress è un bersaglio privilegiato

Con oltre il 43% di quota di mercato globale, WordPress è la piattaforma web più diffusa al mondo. Questo la rende anche la più attaccata: i bot scansionano continuamente internet alla ricerca di installazioni WordPress con plugin vulnerabili, versioni non aggiornate e configurazioni di default mai modificate.

Nel 2025 il team di ricerca Patchstack ha rilevato 11.334 nuove vulnerabilità nell’ecosistema WordPress, un aumento del 42% rispetto all’anno precedente. Il dato più rilevante è che il 97% di queste falle non si trova nel codice base di WordPress, ma nei plugin e nei temi di terze parti. Un sito WordPress aggiornato ma con un plugin abbandonato o non mantenuto è esposto esattamente come un sito con WordPress vecchio di due anni.

Il meccanismo è rapido e automatizzato: un hacker scopre una vulnerabilità in un plugin diffuso, crea un bot che scansiona internet alla ricerca di siti che lo usano, e lancia attacchi di massa. Dalla scoperta della falla all’inizio degli attacchi possono passare meno di cinque ore. Nessuna agenzia che gestisce decine di siti in manutenzione può monitorare questo in tempo reale senza un processo strutturato.

Cosa abbiamo trovato sui siti in manutenzione

Nei controlli periodici che facciamo sui siti in manutenzione per le agenzie con cui collaboriamo, i problemi di sicurezza più comuni che troviamo sono sempre gli stessi.

Plugin non aggiornati sono il problema più diffuso. Spesso si tratta di plugin installati anni fa per una funzionalità specifica, usati raramente e mai aggiornati perché “funzionano ancora”. Funzionano, ma hanno vulnerabilità note che i bot sfruttano sistematicamente.

Credenziali di accesso deboli sono il secondo problema. Ancora nel 2026 troviamo siti con username “admin” e password semplici. È il tipo di protezione che un attacco brute force automatizzato supera in pochi minuti.

Nessun sistema di blocco dei tentativi di login è il terzo. Senza un meccanismo che limiti i tentativi di accesso o blocchi gli IP dopo un certo numero di tentativi falliti, la pagina di login di WordPress è esposta a attacchi brute force continui che non generano nessun alert fino a quando non hanno già avuto successo.

SSL non configurato correttamente emerge ancora su siti più datati: HTTP e HTTPS che coesistono, contenuti misti, certificati scaduti. Non è solo un problema SEO: è una vulnerabilità che espone le comunicazioni tra il sito e i suoi utenti.

La situazione specifica dell’Italia nel 2026

Il dato italiano ha una caratteristica peculiare che il Rapporto CLUSIT 2026 sottolinea: l’Italia nel 2025 ha ospitato il 64% di tutti gli incidenti di hacktivism censiti a livello globale. Attacchi motivati da ragioni ideologiche e geopolitiche, principalmente DDoS e defacement dei siti, orchestrati da collettivi che prendono di mira infrastrutture italiane in risposta a eventi internazionali.

Questo significa che i siti web dei clienti delle agenzie italiane sono esposti non solo agli attacchi opportunistici automatizzati che colpiscono WordPress ovunque nel mondo, ma anche ad attacchi mirati che scelgono l’Italia come bersaglio per ragioni che non hanno nulla a che fare con la qualità tecnica del sito. Un sito tecnicamente perfetto può essere vittima di un attacco DDoS semplicemente perché ha un IP italiano.

Il costo medio di un attacco ransomware per una PMI italiana è stimato intorno ai 35.000 euro, tra riscatto, ripristino dei sistemi e perdita di produttività. Per un cliente che gestisce un ecommerce attivo, anche un downtime di 24 ore ha un impatto diretto sulle vendite che supera spesso il costo di anni di manutenzione professionale.

Cosa significa per le agenzie che gestiscono siti WordPress

Il tema della sicurezza dei siti web non è un argomento tecnico separato dalla relazione con il cliente: è un rischio che, se si materializza, ricade sull’agenzia indipendentemente da chi ha causato la vulnerabilità. Un cliente che scopre che il proprio sito è stato hackerato chiama l’agenzia, non il provider del plugin vulnerabile.

Lavorare con uno stack tecnico selezionato riduce il rischio in modo strutturale. Usare pochi plugin mantenuti attivamente, affidarsi a Cloudflare come layer di sicurezza perimetrale che blocca il traffico malevolo prima che raggiunga il server WordPress, mantenere aggiornamenti sistematici con testing su staging prima dell’applicazione in produzione: sono scelte che noi di Blurr abbiamo consolidato nel tempo proprio perché i dati sugli attacchi ci dicono che la superficie di attacco si riduce drasticamente con la disciplina operativa più che con i tool sofisticati.

Il secondo elemento è la manutenzione come presidio attivo, non come lista di aggiornamenti mensili. Monitorare l’uptime, verificare i log di accesso, controllare i tentativi di login non autorizzati, testare i backup con ripristini periodici: sono attività che separano una manutenzione professionale da una che esiste solo sulla carta.

Blurr include questo presidio nei piani di manutenzione per le agenzie partner: monitoraggio attivo, aggiornamenti testati su staging, Cloudflare come layer di sicurezza su tutti i siti, backup verificati con test di ripristino periodici. Le agenzie che affidano la manutenzione a Blurr non devono gestire questa complessità in autonomia. Su blurr.it/servizi/ trovi come strutturiamo la sicurezza nei piani di manutenzione.

Per approfondire lo stack tecnico che usiamo per la sicurezza dei siti WordPress, leggi plugin WordPress essenziali per siti professionali nel 2026.

FAQ

Perché i siti WordPress sono così vulnerabili agli attacchi?

Non per debolezze intrinseche di WordPress, ma per la combinazione di diffusione massima e gestione spesso approssimativa. Con il 43% del web mondiale su WordPress, i bot automatizzati scansionano sistematicamente internet alla ricerca di installazioni con plugin non aggiornati o configurazioni deboli. Il 97% delle vulnerabilità WordPress nel 2025 riguardava plugin e temi di terze parti, non il core di WordPress.

Quanto costa in media un attacco informatico a una PMI italiana?

Secondo i dati disponibili, il costo medio di un attacco ransomware per una PMI italiana si aggira intorno ai 35.000 euro, considerando riscatto, ripristino dei sistemi e perdita di produttività. Per un ecommerce attivo, il downtime associato all’attacco aggiunge costi diretti in vendite perse che possono superare significativamente quella cifra.

Cloudflare è sufficiente per proteggere un sito WordPress?

Cloudflare è un layer di sicurezza perimetrale molto efficace perché blocca traffico malevolo, attacchi DDoS e tentativi di brute force prima che raggiungano il server WordPress. Non è sufficiente da solo: va combinato con aggiornamenti sistematici dei plugin, credenziali di accesso solide, backup verificati e un sistema di monitoraggio attivo. È il primo strato di una difesa a più livelli, non l’unico.

Come si verifica se un sito WordPress è stato compromesso?

I segnali più comuni sono reindirizzamenti improvvisi verso siti sconosciuti, avvisi di sito pericoloso da Google, calo improvviso del traffico organico, comparsa di pagine o link mai creati, e notifiche dall’hosting di attività anomale. Google Search Console nella sezione Problemi di sicurezza segnala le compromissioni rilevate da Google. Un controllo periodico di questi indicatori dovrebbe essere parte di qualsiasi piano di manutenzione professionale.