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
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 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.
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.
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.