Un sito aziendale compromesso può smettere di generare contatti, mostrare spam SEO o inviare email sospette. Spesso il problema nasce da un plugin dimenticato, un accesso admin troppo aperto o una configurazione server lasciata di default.
L’hardening WordPress riduce questi rischi con controlli tecnici concreti. Non basta installare un plugin di sicurezza e considerarlo l’unico elemento della sicurezza di WordPress, o WordPress security.
Parti dalle priorità che bloccano gli attacchi più comuni, senza rompere form, e-commerce o integrazioni importanti.
Punti chiave da controllare subito
- Aggiorna core, tema e plugin solo dopo un backup verificato e un test in staging.
- Proteggi gli account amministratore con password uniche, ruoli limitati e autenticazione a due fattori.
- Chiudi le funzioni che non usi, come XML-RPC o l’editor dei file nella bacheca.
- Configura server, permessi e firewall in base al tuo hosting, non copiando regole trovate online.
- Controlla log, uptime, form, email e backup ogni mese. Un backup mai ripristinato resta una speranza.
1. Aggiorna core, tema e plugin
WordPress aggiornato è il primo livello di protezione. Core, plugin e temi ricevono patch che riducono security vulnerabilities già note, ma non sostituiscono i test. Valuta gli aggiornamenti automatici (automatic updates) per le componenti affidabili e compatibili con il tuo sito.
Prima dell’intervento crea una copia completa di file, database e configurazioni. Conservane almeno una fuori dal server principale. Poi testa l’aggiornamento su staging, protetto con password e impostato come noindex.
Se qualcosa smette di funzionare, annota data, ora e sintomo. Pagina bianca, errore 500, login bloccato, modulo che non invia email. Controlla anche cache del browser, CDN, cache server e plugin cache. A volte il sito funziona, ma una vecchia pagina in cache racconta un’altra storia.
Le linee guida ufficiali sulla sicurezza di WordPress confermano una regola semplice: mantieni aggiornati WordPress, estensioni e temi. Rimuovi anche ciò che non usi. Un plugin disattivato ma installato può restare vulnerabile.
Per trasformare questo lavoro in routine, segui un workflow di manutenzione per siti aziendali, con verifiche, backup e test dopo ogni aggiornamento. Puoi affiancare anche un controllo di vulnerability scanning, utile per verificare plugin dismessi e componenti non aggiornati, senza sostituire backup, staging e aggiornamenti.
2. Riduci gli accessi e proteggi il login
Il pannello WordPress non deve essere accessibile a più persone del necessario. Ogni account amministratore (admin account) aggiuntivo aumenta il rischio di password deboli, credenziali condivise e modifiche non tracciate. Un buon controllo degli accessi (access control) migliora anche la tracciabilità.
Assegna ruoli minimi e verifica gli account
Controlla gli utenti con ruoli amministratore, editore e autore. Elimina gli account che non riconosci, dopo aver trasferito eventuali contenuti a un utente legittimo.
Un collaboratore che pubblica articoli non deve poter installare plugin, modificare il tema o cambiare configurazioni. Assegna il ruolo minimo compatibile con il lavoro da svolgere, secondo il principio dei user roles.
Rivedi la lista utenti almeno una volta al mese. Verifica anche che i user roles siano ancora adeguati alle responsabilità attuali. Quando un collaboratore termina il rapporto, disattiva subito l’accesso. Non aspettare.
Attiva la 2FA per chi gestisce il sito
La password non basta, soprattutto per gli amministratori. L’autenticazione a due fattori, o two-factor authentication, aggiunge un secondo controllo tramite app autenticatore, codice temporaneo o chiave fisica.
Il plugin ufficiale Two Factor per WordPress aggiunge questo livello al login. Attiva la two-factor authentication almeno per amministratori, sviluppatori e persone che gestiscono ordini o dati personali.
Applica anche il rate limiting ai login attempts. Dopo più password errate, l’indirizzo IP deve essere temporaneamente bloccato. Questo riduce i tentativi automatizzati e l’impatto dei brute-force attacks, ma non sostituisce password uniche, 2FA e ruoli corretti.
3. Disabilita XML-RPC se non serve
Il file xmlrpc.php permette a servizi esterni di comunicare con WordPress. Può essere utile, ma può anche esporre il sito a brute-force attacks, pingback indesiderati e traffico senza rate limiting.
Quando puoi bloccarlo senza problemi
Se il sito è una vetrina aziendale e non usa app mobili WordPress, client remoti o servizi legacy, puoi disabilitare XML-RPC. Una soluzione semplice è usare un plugin dedicato, oppure una regola lato server impostata correttamente.
WordPress segnala che XML-RPC va disabilitato quando non necessario. Se invece resta attivo, va protetto con rate limiting e controlli sul traffico. Consulta le indicazioni sui brute-force e XML-RPC prima di bloccarlo in modo definitivo.
Verifica cosa può smettere di funzionare
Non applicare il blocco alla cieca. Jetpack, app WordPress e alcune integrazioni esterne possono dipendere da XML-RPC.
Fai una prova in staging. Controlla pubblicazione remota, statistiche, sincronizzazioni e funzioni Jetpack. Se un’integrazione serve davvero, non spegnerla. Limitala con firewall, rate limiting e autenticazione forte.
Cambiare l’URL di accesso o bloccare
wp-login.phpnon protegge XML-RPC. Sono due superfici d’attacco diverse.
4. Proteggi wp-config.php e disabilita l’editor file
Il file wp-config.php contiene dati sensibili: credenziali del database, chiavi di sicurezza e impostazioni del sito. Va trattato come un file riservato.
Sposta e limita il file di configurazione
Quando l’hosting lo consente, wp-config.php può stare una directory sopra la root di WordPress. In questo modo non si trova nella cartella pubblica dell’installazione. Disabilita anche directory listing e directory browsing quando non servono, così i contenuti delle directory non restano esposti.
I permessi del file, o file permissions, vanno adattati all’utente che esegue PHP e alla configurazione dell’hosting. Valori come 400 o 440 possono essere più restrittivi, ma non sono una regola universale. Un valore troppo chiuso può causare errore 500 o pagina bianca.
Se devi attivare il debug per un problema, mantieni WP_DEBUG_DISPLAY su false. Gli errori vanno nei log, non davanti ai visitatori.
Blocca l’editor di temi e plugin
Disabilitare il file editing limita l’editor interno di WordPress. Un account amministratore compromesso potrebbe usarlo per inserire malicious code in un file PHP. Per bloccare questa possibilità, aggiungi la costante in wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );
Questa impostazione rimuove l’editor di file dalla bacheca e blocca le modifiche da quell’interfaccia. Non sostituisce il blocco della PHP execution nelle directory scrivibili. Inoltre, non blocca l’installazione o l’aggiornamento di plugin e temi. Per questo servono user roles corretti e una procedura di aggiornamento controllata.
5. Correggi permessi e blocca PHP nella cartella uploads
I file permissions non sono dettagli da sistemista. Incidono direttamente sulla sicurezza del sito. Permessi troppo aperti permettono modifiche non autorizzate. Permessi troppo stretti possono bloccare aggiornamenti, caricamenti e cache.
Usa 644 per i file e 755 per le cartelle
Come base, WordPress indica 644 per i file e 755 per le directory. Questa configurazione di file permissions è normalmente compatibile con molti hosting condivisi e VPS configurati correttamente.
Non impostare 777 per “far funzionare tutto”. È una scorciatoia pericolosa. Se un plugin richiede permessi così aperti, verifica prima proprietà dei file, utente PHP e configurazione del server.
Controlla anche le cartelle meno visibili, come wp-content/mu-plugins, i temi non attivi e i plugin dismessi. File sconosciuti o script PHP in cartelle insolite meritano un controllo.
Impedisci l’esecuzione PHP in uploads
La directory wp-content/uploads dovrebbe contenere immagini, PDF e documenti, senza esporre un directory listing. Se un attaccante riesce a caricare uno script PHP, la PHP execution può consentire l’esecuzione di malicious code e compromettere il sito.
Blocca l’esecuzione PHP nella cartella uploads con una regola adatta al server. Apache e LiteSpeed possono usare direttive compatibili con .htaccess. Nginx richiede una configurazione location lato server.
Non copiare regole Apache dentro Nginx. Non funzionano. Per la server security, la regola deve essere coerente con la configurazione effettiva dell’hosting. Con LiteSpeed, controlla il comportamento reale del server.
Dopo la modifica, prova il caricamento di immagini, PDF, form con allegati e funzioni WooCommerce. Verifica anche il directory listing e che la PHP execution sia bloccata in wp-content/uploads, senza impedire i caricamenti normali.
6. Metti un WAF davanti al sito e proteggi l’URL di login
Un Web Application Firewall filtra le richieste sospette prima che arrivino a WordPress. Può bloccare tentativi di login ripetuti, inclusi i brute-force attacks, scanner automatici, richieste malevole e traffico anomalo.
Scegli un firewall gestito e monitora gli avvisi
Puoi usare un WAF a livello server, una CDN con protezione applicativa o un plugin firewall, cioè un security plugin come Wordfence o Sucuri. La scelta dipende da hosting, budget, traffico e capacità di monitoraggio.
Per una PMI conta più la configurazione del nome del prodotto. Attiva notifiche per login sospetti, file modificati, malicious requests bloccate e blocchi frequenti. Un firewall senza controllo degli alert diventa solo un’icona verde in bacheca.
Cambia l’URL di login come misura aggiuntiva
Il login URL standard wp-login.php attira continuamente i bot. Un URL personalizzato riduce il rumore e i tentativi automatici più banali.
Non considerarlo una difesa completa. Un bot evoluto può individuare altre vie di accesso. Usa un plugin affidabile, escludi il nuovo URL dalla cache e conserva il percorso in un gestore password.
Se perdi l’URL personalizzato, l’accesso admin può diventare più complicato. Documenta sempre il nuovo login URL e verifica il login anche da una finestra anonima.
7. Applica header di sicurezza e regole adatte al server
Gli security headers rafforzano la protezione del browser. Non eliminano le vulnerabilità nel codice, ma limitano alcuni attacchi e comportamenti indesiderati.
Parti da HSTS e protezione dal clickjacking
Strict-Transport-Security comunica al browser di usare HTTPS. Prima di impostare una policy lunga, verifica che il sito e tutti i sottodomini abbiano un SSL certificate valido e funzionante. Un valore comune è max-age=31536000; includeSubDomains, ma applicalo solo quando tutti i sottodomini usano HTTPS senza eccezioni.
X-Frame-Options: SAMEORIGIN riduce il rischio di clickjacking, cioè l’apertura del sito dentro un frame esterno ingannevole. Una Content Security Policy può usare anche frame-ancestors per definire con più precisione chi può incorporare le tue pagine.
Testa la CSP prima di pubblicarla
Una CSP troppo rigida può bloccare Google Maps, font, cookie banner, video, chat, analytics e script di Elementor. Prima testala in staging o in modalità report-only.
Controlla pagine contatti, moduli di richiesta preventivo, checkout, login e aree riservate. Una sicurezza che blocca le richieste commerciali non è una buona configurazione.
Gli header fanno parte anche della SEO tecnica per siti WordPress. Un sito compromesso, lento o pieno di redirect anomali perde fiducia, visite e richieste.
Un sito protetto resta un sito gestito
La sicurezza del sito WordPress non è un intervento da fare una volta e dimenticare. Aggiornamenti, backup testati, user roles, WAF e log devono lavorare insieme.
Il controllo più utile è quello ripetuto nel tempo, seguendo le security best practices. Dopo ogni modifica importante, verifica homepage, form, email, login, checkout, tracciamenti e velocità del sito.
Una configurazione ordinata migliora la security posture e riduce gli imprevisti. Quando arriva un problema, ti permette di capire subito dove intervenire.
Domande frequenti sull’hardening WordPress
Quali sono i permessi consigliati per WordPress?
Come configurazione di base, usa 644 per i file e 755 per le cartelle. wp-config.php può richiedere 400 o 440, ma dipende dall’utente PHP e dalla configurazione dell’hosting.
Disabilitare XML-RPC può creare problemi?
Sì. Può interferire con Jetpack, app WordPress, client remoti e integrazioni meno recenti. Testa tutto in staging prima di bloccarlo sul sito online.
Un WAF sostituisce backup e aggiornamenti?
No. Il WAF filtra richieste sospette, ma non aggiorna plugin vulnerabili e non recupera dati persi. Servono anche backup esterni, aggiornamenti e un ripristino testato.
