Checklist sicurezza WordPress: 25 controlli da fare

Mettere in sicurezza WordPress non significa installare un plugin e considerare chiuso il problema. Significa verificare, una per una, un numero finito di cose: come si entra nel sito, cosa è raggiungibile dall’esterno, cosa gira sul server, chi ti avvisa quando qualcosa non va e quanto ci metti a rimettere tutto in piedi se va male davvero. Questa checklist raccoglie i 25 controlli che faccio su ogni installazione, dal più elementare al più trascurato.

Non è una lista di plugin consigliati. Ogni controllo dice cosa si verifica, come si verifica in concreto — con quale schermata, quale URL, quale comando — come si corregge in WordPress e a quale condizione puoi considerarlo superato. Puoi percorrerla in ordine oppure andare direttamente al blocco che ti interessa: i controlli sono indipendenti fra loro.

Se hai poco tempo, i primi undici valgono più di tutti gli altri messi insieme: la maggior parte dei siti WordPress compromessi non cade per un attacco sofisticato, ma per un plugin non aggiornato o una password riusata.

Prima di iniziare

Ti servono tre cose: un account con ruolo Amministratore (verificalo in Utenti > Il tuo profilo), l’accesso ai file del sito via SFTP o file manager dell’hosting — diversi controlli richiedono di aprire wp-config.php o le regole del server — e soprattutto un backup completo e recente, file e database, fatto prima di toccare qualsiasi cosa. Se non ne hai uno, parti dal controllo 24 e poi torna qui.

Verifica anche che l’indirizzo email amministratore in Impostazioni > Generali sia valido e riceva davvero posta: metà dei controlli di monitoraggio di questa checklist passa da lì.

Blocco A — Fondamenta

Cinque controlli sull’ambiente in cui gira WordPress. Sono i più noiosi e i più decisivi: nessuna configurazione di sicurezza compensa un software non aggiornato.

1. La versione di PHP è ancora supportata

WordPress continua a funzionare su versioni di PHP arrivate a fine vita, e questo è esattamente il problema: il sito sembra a posto mentre il runtime sotto non riceve più patch di sicurezza. È il controllo che salta più spesso sui siti “che funzionano da anni”.

Come si verifica: Strumenti > Salute del sito > Info > Server, voce “Versione PHP”. Confronta il numero con l’elenco delle versioni con supporto attivo sul sito ufficiale di PHP.

Come si corregge: l’aggiornamento si fa dal pannello dell’hosting, non da WordPress. Prima però verifica la compatibilità di plugin e temi e fai la prova su un ambiente di staging: un salto di versione major può rompere codice che non veniva toccato da tempo. Se il sito è su VPS, il passaggio è a livello di PHP-FPM: nella guida a WordPress self-hosted ho descritto come è configurato lo stack.

✅ Fatto quando: la versione che leggi in Salute del sito è tra quelle con supporto di sicurezza attivo alla data di oggi.

2. Il core è aggiornato e gli aggiornamenti minori sono automatici

Le release minori di WordPress (da 7.0.3 a 7.0.4, per intenderci) sono quasi sempre patch di sicurezza, e vengono rilasciate proprio quando una vulnerabilità è diventata pubblica. La finestra tra il rilascio e lo sfruttamento di massa si misura in ore. La 7.0.4 dell’agosto 2026 è un esempio da manuale: correggeva una falla di esecuzione di codice da remoto, e la differenza fra release minori e major è esattamente il motivo per cui le prime vanno lasciate automatiche.

Come si verifica: Bacheca > Aggiornamenti per la versione installata. Per gli aggiornamenti automatici, controlla in wp-config.php che non ci sia una costante WP_AUTO_UPDATE_CORE impostata a false, e nel tema o in un plugin funzionale che nessun filtro auto_update_core_minor li stia disattivando.

Come si corregge: aggiorna, poi riattiva gli automatismi per i minori. Gli aggiornamenti major conviene invece tenerli manuali e programmati: la procedura completa di aggiornamento spiega come gestirli senza sorprese.

✅ Fatto quando: la versione installata è l’ultima stabile e gli aggiornamenti minori automatici risultano attivi.

3. Plugin e temi sono aggiornati, e quelli inutilizzati sono disinstallati

Un plugin disattivato non è un plugin innocuo: i suoi file restano sul disco e restano raggiungibili via HTTP. Diverse compromissioni note sono passate da plugin che il proprietario del sito credeva “spenti”. Disattivare non basta, va disinstallato.

Come si verifica: Plugin > Installati, filtro “Inattivi”, e Aspetto > Temi. Conta quanti ce ne sono che nessuno usa da mesi.

Come si corregge: aggiorna tutto quello che serve, elimina tutto quello che non serve. Tieni un solo tema di default come rete di sicurezza, per poter passare a un tema pulito se il tuo si rompe. Sulla sicurezza dei plugin ho raccolto i criteri per decidere cosa vale la pena tenere.

✅ Fatto quando: zero plugin inattivi installati, al massimo un tema inattivo di riserva, nessun aggiornamento in sospeso.

4. Plugin e temi vengono solo da fonti verificabili

Le versioni nulled di plugin premium sono il modo più diretto per installare una backdoor con le proprie mani: il codice aggiuntivo che rimuove il controllo di licenza raramente si limita a fare quello. Ma il rischio non finisce lì: anche un plugin legittimo può essere compromesso a monte, quando l’autore vende il progetto o subisce un furto di credenziali.

Come si verifica: per ogni plugin, apri la scheda sul repository ufficiale e guarda due dati: data dell’ultimo aggiornamento e compatibilità dichiarata con la tua versione di WordPress. Segna come sospetto tutto ciò che non viene toccato da più di dodici mesi.

Come si corregge: sostituisci i plugin abbandonati con alternative mantenute. Se trovi una versione nulled, rimuoverla non basta: il sito va considerato potenzialmente compromesso e verificato con i controlli 21 e 22. Il caso degli attacchi supply chain su WordPress mostra come funziona questo tipo di compromissione a monte.

✅ Fatto quando: ogni plugin e tema installato ha un’origine tracciabile e almeno un aggiornamento negli ultimi dodici mesi.

5. HTTPS è attivo ovunque e il rinnovo del certificato è automatico

Senza HTTPS i cookie di sessione dell’amministratore viaggiano in chiaro. Con HTTPS ma con risorse caricate in http://, il browser segnala contenuto misto e alcune protezioni decadono. E un certificato che scade di sabato notte perché il rinnovo automatico non ha mai funzionato è un caso più comune di quanto sembri.

Un certificato valido con TLS 1.3 è anche il prerequisito di HTTP/3, il protocollo che esiste solo cifrato: se stai sistemando il certificato adesso, è il momento giusto per verificare anche quello.

Come si verifica: naviga qualche pagina interna e controlla che il lucchetto non mostri avvisi; cerca nel sorgente occorrenze di http:// sul tuo dominio; guarda la data di scadenza del certificato cliccando sul lucchetto.

Come si corregge: forza HTTPS a livello di server, aggiorna gli URL rimasti in database, e verifica che il rinnovo (tipicamente Let’s Encrypt) sia realmente schedulato e sia già andato a buon fine almeno una volta senza intervento manuale.

✅ Fatto quando: tutte le pagine caricano in HTTPS senza avvisi di contenuto misto e hai visto almeno un rinnovo automatico completarsi da solo.

Blocco B — Accessi e autenticazione

Sei controlli sul punto più attaccato di qualsiasi installazione WordPress. La pagina di login riceve tentativi automatizzati dal giorno in cui il dominio compare in un certificato pubblico, indipendentemente dal traffico del sito.

6. Nessun utente si chiama “admin” e i ruoli sono al minimo privilegio

Se l’username è prevedibile, l’attaccante deve indovinare solo la password: gli hai dimezzato il lavoro. Il secondo problema, meno evidente, è il numero di amministratori: ogni account con quel ruolo è una chiave completa del sito, e spesso ne restano in giro di vecchi collaboratori.

Come si verifica: Utenti > Tutti gli utenti, ordina per ruolo e conta gli amministratori. Cerca username come admin, administrator, il nome del dominio o il nome dell’azienda.

Come si corregge: l’username in WordPress non è modificabile dall’interfaccia. Crea un nuovo amministratore con nome non prevedibile, accedi con quello, elimina il vecchio e assegna i suoi contenuti al nuovo account quando WordPress te lo chiede. Poi declassa a Editore o Autore chiunque non abbia bisogno di installare plugin.

✅ Fatto quando: nessun username prevedibile e ogni amministratore rimasto è una persona che, oggi, ha davvero bisogno di quel ruolo.

7. Le password degli amministratori sono robuste e mai riusate

Gli attacchi più efficaci oggi non provano password a caso: provano credenziali già trapelate da altri servizi. Una password perfettamente robusta ma usata anche altrove è, in pratica, una password pubblica.

Come si verifica: le password non sono leggibili — quello che si verifica è il processo. Chiedi a ogni amministratore se la sua password del sito è usata su altri servizi e se è conservata in un password manager. Controlla i tuoi indirizzi su un servizio di segnalazione data breach.

Come si corregge: reset di tutte le password amministratore usando il generatore integrato di WordPress, conservate in un password manager. Dopo il cambio, invalida le sessioni ancora aperte dal profilo utente, altrimenti chi era già dentro resta dentro.

✅ Fatto quando: ogni amministratore ha una password generata casualmente, mai usata su altri servizi, e le vecchie sessioni sono state chiuse.

8. La 2FA è attiva su tutti gli account amministratore ed editore

È la misura con il miglior rapporto tra sforzo e protezione dell’intera checklist: anche con username e password corretti in mano, senza il secondo fattore l’attaccante non entra. Neutralizza in un colpo solo il credential stuffing e buona parte del phishing.

Come si verifica: se usi Wordfence, la sezione Login Security mostra quali utenti hanno la 2FA attiva e quali no. Il dato che conta non è “è disponibile”, è “quanti la usano davvero”.

Come si corregge: il modulo Wordfence Login Security è gratuito e installabile anche da solo, senza il firewall completo. Da Utenti > Il tuo profilo scansiona il QR code con un’app di autenticazione (Google Authenticator, Authy, 1Password), inserisci un codice per attivarla e scarica i codici di recupero: senza quelli, perdere il telefono significa perdere l’accesso. Poi in Login Security > Settings rendila obbligatoria per amministratori ed editori, con un periodo di grazia di 3-7 giorni per dare tempo agli altri utenti di configurarla.

✅ Fatto quando: ogni account amministratore ed editore ha la 2FA attiva e i codici di recupero conservati fuori dal sito.

9. I tentativi di login sono limitati con blocco progressivo

WordPress, di suo, accetta tentativi di accesso all’infinito. Limitarli non serve solo a fermare il brute force: serve anche a evitare che migliaia di richieste al minuto mettano in ginocchio il server, che è il modo in cui questi attacchi fanno danno anche quando falliscono.

Come si verifica: sbaglia deliberatamente la password quattro o cinque volte da una finestra in incognito. Se al sesto tentativo il form risponde ancora normalmente, non c’è alcun limite attivo.

Come si corregge: Limit Login Attempts Security è leggero e sufficiente, utile soprattutto su hosting condivisi dove un plugin più pesante peserebbe sulle prestazioni. Configurazione consigliata: 3 tentativi consentiti, blocco di 20 minuti, e dopo 3 blocchi consecutivi sospensione di 24 ore — è quest’ultimo parametro a fermare gli attacchi automatizzati persistenti. Attiva la notifica email sul blocco e la modalità GDPR se tratti dati di utenti europei. In alternativa, la stessa funzione è integrata nel firewall del controllo 18. Sul funzionamento degli attacchi brute force e DDoS ho spiegato perché il blocco progressivo conta più della soglia iniziale. Quali porte il limite deve coprire — il modulo di login, XML-RPC, la REST API con le password applicazione, i moduli dei plugin — e come lo si verifica dal terminale l’ho scritto in come si contano i tentativi di login porta per porta.

✅ Fatto quando: dopo pochi tentativi falliti l’IP viene bloccato, e i blocchi ripetuti allungano la durata del blocco.

10. Login e form pubblici hanno una protezione anti-bot

Il limite sui tentativi agisce dopo che la richiesta è arrivata. Una protezione anti-bot agisce prima, scartando il traffico automatizzato senza chiedere nulla all’utente reale — e copre anche registrazione, recupero password e commenti, che spesso restano scoperti mentre ci si concentra sul login.

Come si verifica: apri la pagina di login in incognito e controlla dagli strumenti per sviluppatori che venga caricato lo script del servizio anti-bot. Poi ripeti su registrazione e recupero password: è lì che di solito manca.

Come si corregge: reCAPTCHA v3 lavora in background assegnando a ogni visitatore un punteggio da 0.0 a 1.0, senza sfide visive: crea le chiavi dalla console di amministrazione di Google scegliendo il tipo v3, poi inseriscile in un plugin di integrazione e attiva la protezione su login, registrazione, recupero password e commenti, con soglia 0.5 come punto di partenza. Se preferisci non passare dati a Google, Cloudflare Turnstile fa la stessa cosa ed è più lineare dal punto di vista privacy, specialmente se stai già usando Cloudflare per il controllo 19.

✅ Fatto quando: login, registrazione, recupero password e commenti sono tutti protetti, e un invio legittimo passa senza attriti.

11. L’URL di login è cambiato — sapendo cosa fa e cosa non fa

Va detto con onestà: spostare wp-login.php è security by obscurity. Non rende il login più sicuro, rende il sito meno visibile ai bot che scandagliano indirizzi noti. Il beneficio reale è concreto ma diverso da quello che si racconta di solito: crollano il rumore nei log e il carico generato dai tentativi automatici, il che rende molto più leggibili i controlli 22 e 23. Non sostituisce la 2FA né il limite sui tentativi.

Come si verifica: apri /wp-login.php da una finestra in incognito. Se compare il form di accesso, l’URL è quello standard.

Come si corregge: WPS Hide Login non modifica i file core ed è reversibile in qualsiasi momento; le sue opzioni compaiono in fondo a Impostazioni > Generali. Scegli uno slug che non contenga “admin”, “wp” o “login”. Due precauzioni prima di salvare: annota il nuovo indirizzo in un posto sicuro e provalo da una finestra in incognito senza chiudere la sessione corrente, perché da quel momento wp-login.php smette di rispondere.

✅ Fatto quando: il vecchio indirizzo non risponde più, il nuovo funziona da sessione pulita ed è annotato fuori dal sito.

Blocco C — Superficie d’attacco e configurazione

Sei controlli su ciò che WordPress espone senza che tu glielo abbia chiesto. Sono i più tecnici della checklist e i meno presidiati: quasi nessuno li tocca dopo l’installazione.

12. XML-RPC è disattivato o limitato

Il file xmlrpc.php permette a servizi esterni di dialogare con il sito: app mobile di WordPress, Jetpack, pubblicazione remota. È anche uno dei bersagli preferiti per il brute force — non perché permetta di provare centinaia di credenziali in una richiesta, come si legge ancora spesso: dalla 4.4 una richiesta XML-RPC autentica una volta sola, anche dentro system.multicall — ma perché non ha CAPTCHA né un indirizzo da nascondere, e il limite del controllo 9 la copre solo se conta i tentativi dentro WordPress e non le richieste alla pagina di login.

Come si verifica: apri https://iltuosito.it/xmlrpc.php. Il messaggio “XML-RPC server accepts POST requests only” significa che è attivo. Un 403 o un 404 significano che è bloccato.

Come si corregge: se non usi app mobile né Jetpack, disattivalo del tutto — un plugin dedicato lo fa senza configurazione, ma bloccarlo a livello di server è più efficiente perché la richiesta non arriva nemmeno a PHP. Su Apache, in .htaccess:

<Files xmlrpc.php>
  Require all denied
</Files>

Se invece ti serve, non lasciarlo aperto: limita system.multicall, disattiva pingback e trackback e consenti l’accesso solo dagli IP dei servizi che lo usano davvero.

✅ Fatto quando: l’URL risponde 403, oppure è raggiungibile solo dagli IP autorizzati e senza system.multicall.

13. La REST API non espone l’elenco degli utenti

Di default WordPress pubblica l’elenco degli autori tramite REST API, senza autenticazione. Chiunque può ottenere in pochi secondi username e ID di tutti gli utenti che hanno pubblicato qualcosa: è il passo preliminare di ogni attacco mirato al login, e vanifica in parte il controllo 6.

Come si verifica: apri in incognito /wp-json/wp/v2/users. Se ricevi un JSON con nomi e slug, l’enumerazione è aperta. Prova anche /?author=1: se ti reindirizza alla pagina archivio di un autore — è uno dei redirect che WordPress fa da solo — lo slug nell’URL è l’username.

Un’eccezione va detta, perché altrimenti il controllo diventa un consiglio sbagliato: se l’installazione è usata come backend di un frontend separato, la REST API è il canale da cui il sito viene letto e non si può chiudere. Lì il controllo cambia forma: si limita la frequenza delle richieste e si lasciano aperti solo gli endpoint che il frontend usa davvero.

Come si corregge: quasi tutti i plugin di sicurezza hanno un’opzione pronta per bloccare l’enumerazione degli utenti, che copre entrambe le strade. In alternativa si filtra l’endpoint limitandolo alle richieste autenticate. Attenzione a non rompere integrazioni esistenti che leggono legittimamente gli autori.

✅ Fatto quando: /wp-json/wp/v2/users risponde 401 da utente non autenticato e /?author=1 non rivela alcuno username.

14. L’editor di file dal backend è disattivato

WordPress permette di modificare i file PHP di temi e plugin direttamente dal pannello. Per un attaccante che ottiene un accesso amministratore, è il modo più rapido per trasformare quell’accesso in esecuzione di codice sul server: nessun FTP, nessuno strumento esterno, basta un browser.

Come si verifica: cerca Aspetto > Editor dei file del tema e Plugin > Editor di plugin. Se le voci ci sono, l’editor è attivo.

Come si corregge: aggiungi in wp-config.php, prima della riga che richiama wp-settings.php:

define( 'DISALLOW_FILE_EDIT', true );

Non perdi nulla di utile: modificare codice in produzione senza controllo di versione è comunque una pratica da evitare. Le modifiche al tema, del resto, non vanno fatte lì: si fanno in un child theme, che sopravvive agli aggiornamenti e si carica come qualsiasi altro file.

✅ Fatto quando: le due voci di menu non compaiono più per nessun utente.

15. I file sensibili non sono raggiungibili dal web

È il controllo che produce più sorprese. Backup dimenticati, copie di wp-config.php rinominate durante una modifica, dump del database, cartelle .git caricate per errore: file che nessuno linka ma che chiunque può scaricare conoscendo il nome, e che spesso contengono le credenziali del database in chiaro.

Come si verifica: prova a caricare nel browser questi indirizzi sul tuo dominio: /wp-config.php.bak, /wp-config.php.save, /.env, /backup.sql, /database.sql, /.git/config, /wp-content/uploads/. Ogni risposta diversa da 403 o 404 è un problema. L’ultimo indirizzo, se mostra l’elenco dei file, significa che il directory listing è attivo.

Come si corregge: rimuovi dalla webroot i file che non dovrebbero starci — non limitarti a bloccarli — e disattiva il directory listing a livello di server. Aggiungi una regola che neghi l’accesso alle estensioni di servizio (.bak, .sql, .log, .env) e alle directory nascoste.

✅ Fatto quando: tutti gli indirizzi dell’elenco rispondono 403 o 404 e nessuna cartella mostra il proprio contenuto.

16. I permessi sono corretti e la cartella uploads non esegue PHP

La seconda metà di questo controllo è quella che conta davvero. Molte compromissioni seguono sempre lo stesso schema: un plugin con una falla nell’upload permette di caricare un file PHP tra le immagini, e il server lo esegue perché nessuno gli ha detto di non farlo. Bloccare l’esecuzione di PHP in uploads rende inoffensivo quel file anche quando l’upload riesce.

Come si verifica: i permessi corretti sono 644 per i file, 755 per le cartelle e 640 (o 600) per wp-config.php; una scansione con Wordfence li segnala automaticamente. Per l’esecuzione PHP, carica un file di prova innocuo con estensione .php in wp-content/uploads/ e chiamalo dal browser: deve restituire errore o scaricarsi come testo, mai eseguirsi.

Come si corregge: correggi i permessi via SFTP o da terminale, e aggiungi a livello di server una regola che nega l’esecuzione dei file PHP dentro wp-content/uploads. Ricorda di rimuovere il file di prova quando hai finito.

✅ Fatto quando: i permessi rispettano lo schema sopra e un file PHP dentro uploads non viene eseguito.

17. Le chiavi di sicurezza sono uniche e il debug è spento

Le otto chiavi salt in wp-config.php firmano i cookie di autenticazione. Se sono rimaste ai valori segnaposto — capita nelle installazioni manuali e nei siti clonati da un altro — i cookie di sessione diventano falsificabili. Nello stesso file vive un altro rischio: WP_DEBUG lasciato attivo in produzione, che stampa a video percorsi assoluti e dettagli del database dentro i messaggi di errore.

Come si verifica: apri wp-config.php e cerca la stringa put your unique phrase here: se compare anche una sola volta, le chiavi non sono state generate. Poi controlla che WP_DEBUG e WP_DEBUG_DISPLAY siano a false.

Come si corregge: genera un blocco nuovo dal servizio ufficiale di WordPress e sostituisci le otto righe. Utile sapere che rigenerare le salt invalida tutte le sessioni attive: è una scocciatura in tempi normali, ma è esattamente la prima cosa da fare quando sospetti che qualcuno sia entrato.

✅ Fatto quando: nessun valore segnaposto resta nel file e il debug è disattivato in produzione.

Blocco D — Difesa perimetrale

Tre controlli su ciò che filtra le richieste prima che diventino un problema. Qui si passa dalla configurazione di WordPress agli strati che gli stanno davanti.

18. Un firewall applicativo è attivo in modalità estesa

Un WAF riconosce e blocca le richieste malevole note — SQL injection, tentativi di sfruttare vulnerabilità appena pubblicate — prima che raggiungano il codice. È lo strato che ti protegge nella finestra tra la scoperta di una falla in un plugin e il momento in cui riesci ad aggiornarlo.

Come si verifica: in Wordfence > Firewall lo stato deve essere Enabled and Protecting in modalità Extended Protection. Se resta in Learning Mode a settimane dall’installazione, non sta bloccando nulla: sta solo osservando.

Come si corregge: da Manage Firewall > Optimize the Wordfence Firewall il plugin rileva la configurazione del server, fa il backup del file che deve modificare e attiva la protezione estesa, che intercetta le richieste prima che WordPress venga caricato. Poi imposta il rate limiting: 60 richieste al minuto per singolo visitatore, blocco immediato per i crawler aggressivi e per chi tenta ripetutamente URL inesistenti o file sensibili.

✅ Fatto quando: il firewall è in protezione estesa, non in learning mode, con il rate limiting configurato.

19. C’è una protezione a livello edge con rate limiting

Un firewall applicativo gira sul tuo server: se l’attacco satura la banda o le connessioni disponibili, il server cade comunque. Contro il DDoS serve qualcosa che filtri prima, sulla rete. Cloudflare offre questa protezione anche nel piano gratuito, ed è la differenza tra un sito che rallenta e un sito irraggiungibile.

Come si verifica: controlla che i name server del dominio siano quelli del provider edge e che il traffico risulti effettivamente proxato, non solo in DNS. Nella dashboard devi vedere richieste bloccate: se il numero è fermo a zero da settimane, il proxy probabilmente non è attivo.

Come si corregge: aggiungi il sito, verifica che i record DNS importati siano completi (A, CNAME, MX) e sostituisci i name server presso il registrar. Poi crea una regola di rate limiting sugli endpoint sensibili: sul piano gratuito è una regola sola, contata per IP, con finestra e blocco fissi a dieci secondi — bastano pochi POST in dieci secondi su /wp-login.php (e su /xmlrpc.php, se lo tieni attivo) per farla scattare; le finestre di un minuto e i blocchi più lunghi arrivano con i piani a pagamento. La modalità I’m Under Attack, che interpone una verifica di qualche secondo a ogni visita, va tenuta come misura di emergenza durante un attacco in corso, non come impostazione permanente: penalizza gli utenti reali. Nell’articolo sugli attacchi DDoS trovi la differenza tra i vari livelli di attacco e le mitigazioni corrispondenti.

✅ Fatto quando: il traffico passa dall’edge, esiste una regola di rate limiting sugli endpoint di login e sai dove attivare la modalità di emergenza.

20. Il sito è protetto da scraping e hotlinking

Non è sicurezza in senso stretto, ma è consumo di risorse e danno concreto: bot che copiano i contenuti per ripubblicarli altrove e siti terzi che caricano le tue immagini dal tuo server, facendoti pagare la banda per il loro traffico.

Come si verifica: cerca su Google una frase esatta di un tuo articolo tra virgolette e guarda chi altro la pubblica. Per l’hotlinking, filtra i log del server sulle richieste alle immagini con referrer esterno.

Come si corregge: la protezione hotlink si attiva con un interruttore nel pannello del provider edge. Contro lo scraping non esiste una soluzione definitiva: si alza il costo dell’operazione con rate limiting sui bot dichiarati e blocco degli user-agent noti. Il robots.txt non c’entra — chiede gentilmente, e chi copia non chiede permesso. Attenzione a non estendere questa conclusione ai crawler delle AI: quelli sono dichiarati, e con i bot dichiarati invece funziona — è l’unico strumento che hai per distinguere chi addestra un modello da chi ti indicizza per citarti.

✅ Fatto quando: la protezione hotlink è attiva e hai un modo per accorgerti se i contenuti vengono duplicati.

Blocco E — Rilevamento e monitoraggio

Tre controlli su una domanda sola: se qualcuno entrasse stanotte, quanto tempo passerebbe prima che te ne accorgi? Sui siti che non presidiano questa parte, la risposta media è mesi.

21. Scansione malware e integrità dei file core sono programmate

Il controllo di integrità confronta i file di WordPress, plugin e temi con le versioni originali del repository: se una riga è cambiata, salta fuori. È il modo più affidabile per scoprire una backdoor iniettata in un file legittimo, dove nessuno andrebbe a guardare.

Come si verifica: in Wordfence > Scansione controlla la data dell’ultima esecuzione e che sia pianificata automaticamente. Una scansione lanciata a mano sei mesi fa non è un presidio.

Come si corregge: imposta una scansione automatica almeno settimanale, con confronto dei file core, dei plugin e dei temi, ricerca di codice sospetto e controllo delle vulnerabilità note. Leggi i risultati: dalla dashboard puoi ripristinare i file core modificati e sostituire i plugin vulnerabili. Attenzione ai falsi positivi su plugin premium che non stanno sul repository pubblico — vanno esclusi consapevolmente, una volta verificati.

✅ Fatto quando: esiste una scansione automatica settimanale e l’ultimo report è stato letto, non solo ricevuto.

22. Un registro tiene traccia di accessi e modifiche

Quando qualcosa va storto, la domanda è sempre la stessa: chi ha fatto cosa e quando. Senza un registro non c’è risposta, e non c’è modo di capire da dove è entrato l’attaccante — quindi nemmeno di chiudere quella porta.

Come si verifica: prova a rispondere a una domanda concreta: chi ha modificato le impostazioni del sito il mese scorso? Se non puoi saperlo, il registro non c’è.

Come si corregge: a livello di WordPress, un plugin di activity log registra accessi, modifiche a contenuti e impostazioni, installazioni e cambi di ruolo. A livello di server, i log di accesso sono la fonte più affidabile perché registrano anche ciò che non arriva a WordPress: tentativi ripetuti su wp-login.php o xmlrpc.php, errori 403 e 404 su file sensibili, user-agent di scanner automatici. Su VPS o server dedicato vale la pena aggiungere Fail2Ban, che legge quegli stessi log e blocca gli IP a livello di firewall di sistema — prima ancora che la richiesta arrivi al web server.

✅ Fatto quando: puoi ricostruire chi ha fatto cosa nelle ultime settimane e sai dove sono i log di accesso del server.

23. Le notifiche di sicurezza sono configurate e verificate

Questo controllo esiste separato dagli altri per un motivo preciso: le notifiche configurate ma mai ricevute sono la norma, non l’eccezione. WordPress invia email tramite la funzione PHP mail(), che su molti hosting finisce in spam o non parte affatto — e nessuno se ne accorge finché non serve.

Come si verifica: non basta guardare le caselle spuntate nelle impostazioni. Provoca un evento reale — sbaglia la password abbastanza volte da farti bloccare — e controlla se l’email arriva davvero, anche nella cartella spam.

Come si corregge: attiva le notifiche che contano — accessi bloccati, file core modificati, plugin vulnerabili o disattivati, attacchi bloccati dal firewall — e limita il resto, perché una casella intasata di avvisi irrilevanti equivale a non averne. Se le email non arrivano, configura un invio SMTP autenticato al posto della funzione mail(). Su infrastrutture con più siti, conviene indirizzare gli avvisi su un canale unico anziché su singole caselle.

✅ Fatto quando: hai provocato un evento di test e l’avviso è arrivato in casella, non in spam.

Blocco F — Backup e ripristino

Due controlli sull’unica misura che funziona anche quando tutte le altre hanno fallito. Sono gli ultimi della lista, ma se dovessi tenerne solo due, terrei questi.

24. I backup sono automatici, completi e conservati altrove

Tre requisiti, e servono tutti e tre. Automatici, perché un backup manuale viene fatto finché ci si ricorda. Completi, cioè file e database insieme: un database senza gli upload ricostruisce un sito senza immagini. Altrove, perché un backup che vive nella stessa cartella del sito viene compromesso o cancellato insieme al sito.

Come si verifica: guarda la data dell’ultimo backup riuscito, controlla che includa sia i file sia il database e verifica dove è conservato. Se la risposta è “sul server”, il requisito non è soddisfatto.

Come si corregge: UpdraftPlus copre bene il caso standard: database giornaliero, file settimanale (giornaliero su siti molto attivi o e-commerce), conservazione di 3-5 copie e destinazione remota su Google Drive, Dropbox, S3 o SFTP. Per un controllo maggiore su costi e retention, un backup automatizzato su S3 è la strada che preferisco sui progetti che gestisco.

✅ Fatto quando: esiste un backup automatico di file e database, su storage esterno, con una politica di conservazione definita.

25. Il ripristino è stato testato almeno una volta

È il controllo che quasi nessuno fa, ed è quello che decide se tutto il resto è servito a qualcosa. Un backup mai ripristinato non è un backup: è un file di cui speri qualcosa. Archivi incompleti, dump del database troncati, credenziali di storage scadute mesi prima — sono problemi che si scoprono solo provando, e il momento peggiore per scoprirli è mentre il sito è giù.

Come si verifica: la domanda è semplice. Hai mai ripristinato uno di questi backup? Se la risposta è no, questo controllo non è superato, indipendentemente da quanto sia solido il controllo 24.

Come si corregge: ripristina l’ultimo backup su un ambiente di staging o su un’installazione locale — mai sul sito in produzione. Verifica tre cose: che il sito si apra, che le immagini ci siano e che i contenuti più recenti siano presenti. Annota quanto tempo ci hai messo: quello è il tuo tempo di recupero reale, il numero da comunicare quando qualcuno chiede “in quanto torniamo online?”. Ripeti la prova almeno una volta l’anno e dopo ogni trasferimento del sito su un altro server.

✅ Fatto quando: hai completato un ripristino di prova e sai quanto tempo richiede.

I 25 controlli in breve

Il riepilogo da tenere aperto mentre lavori. La colonna “Priorità” indica cosa fare per primo se non puoi fare tutto in una volta.

Quali strumenti coprono quali controlli

Non servono venticinque strumenti diversi. Con quattro o cinque si copre quasi tutta la checklist, e diversi controlli non richiedono alcun plugin: solo una modifica alla configurazione.

Domande frequenti

Da qui in avanti

La sicurezza di WordPress non è uno stato che raggiungi e poi mantieni: è una manutenzione. I plugin che oggi sono aggiornati domani non lo saranno, la 2FA di un collaboratore che se ne va va revocata, il backup che funziona da un anno smette di funzionare il giorno in cui scade un token. Per questo i controlli 2, 3, 21 e 24 vanno automatizzati e i restanti vanno ripercorsi periodicamente: un piano di manutenzione ricorrente è il modo per non ritrovarsi a rifare tutto da capo tra due anni.

Se questo formato ti è utile, applico lo stesso metodo al posizionamento sui motori di ricerca nella checklist SEO on-page per WordPress e alla conformità del sito nella checklist di accessibilità WordPress: stessa struttura, controlli verificabili uno per uno.

Se preferisci che questi venticinque controlli li faccia io sul tuo sito — verifica completa, correzione di quello che non passa e configurazione di firewall, backup e monitoraggio — puoi vedere come lavoro sulla sicurezza dei siti WordPress.