Il file wp-config.php nella directory principale di ogni installazione WordPress contiene le credenziali del database (host, nome, utente, password), le chiavi di sicurezza segrete e i salt, oltre a costanti di configurazione centrali. Se questo file finisce nelle mani sbagliate, praticamente l'intero sito è compromesso. È quindi il singolo file più importante da proteggere. Questa guida mostra quattro misure di hardening: generare chiavi di sicurezza nuove, impostare permessi restrittivi sui file, bloccare l'accesso HTTP diretto al file e aggiungere costanti protettive come DISALLOW_FILE_EDIT. In opzione, il file può essere spostato un livello sopra la webroot. Tutti i passaggi si eseguono in circa 20 minuti tramite SFTP/SSH e la configurazione .htaccess o nginx.
Passo 1: Rigenerare chiavi di sicurezza e salt
WordPress usa otto stringhe segrete (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY e i quattro valori _SALT corrispondenti) per cifrare i cookie di login e i nonce. Se questi valori sono mai stati pubblici (ad esempio in un backup accessibile sul web) o non sono mai stati cambiati, dovresti rigenerarli. WordPress mette a disposizione un generatore ufficiale:
# Fetch current random values:
https://api.wordpress.org/secret-key/1.1/salt/In wp-config.php, sostituisci il blocco esistente con i valori appena generati:
define( 'AUTH_KEY', 'hier-langer-zufallswert' );
define( 'SECURE_AUTH_KEY', 'hier-langer-zufallswert' );
define( 'LOGGED_IN_KEY', 'hier-langer-zufallswert' );
define( 'NONCE_KEY', 'hier-langer-zufallswert' );
define( 'AUTH_SALT', 'hier-langer-zufallswert' );
define( 'SECURE_AUTH_SALT', 'hier-langer-zufallswert' );
define( 'LOGGED_IN_SALT', 'hier-langer-zufallswert' );
define( 'NONCE_SALT', 'hier-langer-zufallswert' );Dopo il salvataggio, tutti gli utenti connessi vengono disconnessi – è voluto ed è un modo efficace per invalidare le sessioni rubate.
Passo 2: Impostare i permessi dei file
wp-config.php dovrebbe essere leggibile dal web server ma non accessibile agli altri utenti. Si consiglia 600 (solo il proprietario può leggere/scrivere) oppure 640 se il gruppo del web server necessita di accesso in lettura:
# Only owner reads and writes
chmod 600 wp-config.php
# Alternatively, if the web server group must read
chmod 640 wp-config.phpNon impostare mai 777 o 666 – così qualsiasi utente sul sistema può leggere il file ed estrarre le credenziali del database.
Passo 3: Bloccare l'accesso HTTP diretto
Normalmente wp-config.php viene eseguito come PHP e non produce output. Se però l'elaborazione PHP viene meno (configurazione errata, migrazione del server), il contenuto in chiaro potrebbe essere servito. Blocca l'accesso diretto anche a livello di web server.
Apache (.htaccess)
<Files wp-config.php>
Require all denied
</Files>nginx
location = /wp-config.php {
deny all;
return 403;
}Passo 4: Aggiungere costanti di hardening
In wp-config.php, sopra la riga /* That's all, stop editing! */, aggiungi le seguenti costanti:
// Disable the file editor in the admin area (prevents editing
// theme and plugin code via wp-admin)
define( 'DISALLOW_FILE_EDIT', true );
// Optional: completely prevent installing/updating plugins and
// themes via the dashboard (strictest variant)
// define( 'DISALLOW_FILE_MODS', true );
// Disable debug output in production
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
// Enforce encrypted connections in the admin area only
define( 'FORCE_SSL_ADMIN', true );
// Limit automatic core updates to security releases
define( 'WP_AUTO_UPDATE_CORE', 'minor' );DISALLOW_FILE_EDIT è particolarmente importante: senza questa costante, un aggressore che prende il controllo di un account amministratore può eseguire codice PHP arbitrario direttamente da Aspetto » Editor dei temi.
Opzionale: Spostare wp-config.php fuori dalla webroot
WordPress cerca wp-config.php anche un livello di directory sopra la webroot. Se il tuo WordPress si trova in /var/www/html/, puoi spostare il file in /var/www/wp-config.php. Così si trova fuori dall'area raggiungibile via HTTP.
Attenzione: Funziona in modo affidabile solo nelle installazioni classiche single site con webroot dedicata. Sull'hosting condiviso, dove più siti condividono lo stesso livello superiore, lo spostamento può causare conflitti. In caso di dubbio, verifica con il tuo host.
Come verifico che la protezione funzioni?
- Apri
https://tuo-dominio.com/wp-config.phpnel browser. Atteso: una pagina vuota (esecuzione PHP) o 403 Forbidden (accesso bloccato) – mai codice sorgente PHP leggibile. - Da terminale:
curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.com/wp-config.php # Expected: 403 (with an active block) or 200 with an empty body - Controllare i permessi:
ls -l wp-config.php # Expected: -rw------- (600) or -rw-r----- (640) - Nell'area di amministrazione, verifica che sotto Aspetto e Plugin non compaia più alcun editor (effetto di DISALLOW_FILE_EDIT).
Errori frequenti
- Permessi troppo restrittivi: Presso alcuni host PHP non gira come proprietario del file. In tal caso
600può causare un errore 500 – usa allora640o644. - Chiavi sostituite senza backup: Fai una copia del file prima delle modifiche. Un errore di battitura nelle costanti manda il sito offline.
- DISALLOW_FILE_MODS troppo presto: Questa costante blocca anche i normali aggiornamenti di plugin/temi dalla dashboard. Impostala solo se gli aggiornamenti passano esclusivamente da deployment/WP-CLI.
- File spostato, ma percorso errato: Spostandolo fuori dalla webroot, non improvvisare un loader
requirepersonalizzato che esponga un percorso server assoluto.
Domande frequenti (FAQ)
Quale permesso dovrebbe avere wp-config.php?
Si consiglia 600 (solo il proprietario può leggere e scrivere). Se sul tuo host PHP non gira come proprietario del file ma tramite il gruppo, usa 640. Non impostare mai 777 o 666, perché altrimenti qualsiasi utente sul server può leggere le credenziali del database.
Cosa succede se cambio le chiavi di sicurezza in wp-config.php?
Tutti gli utenti connessi vengono disconnessi e devono accedere di nuovo. È voluto ed è un modo efficace per invalidare i cookie di sessione rubati. Il contenuto del sito resta invariato. Genera valori nuovi tramite il generatore ufficiale di chiavi segrete di WordPress.
A cosa serve la costante DISALLOW_FILE_EDIT?
DISALLOW_FILE_EDIT disattiva l'editor di temi e plugin nell'area di amministrazione di WordPress. Senza questa costante, un aggressore che prende il controllo di un account amministratore può eseguire codice PHP arbitrario direttamente da Aspetto » Editor dei temi. La costante è quindi una delle misure di hardening più importanti.
Dovrei spostare wp-config.php fuori dalla webroot?
WordPress cerca wp-config.php anche un livello di directory sopra la webroot. Nelle installazioni classiche single site con webroot dedicata, spostarlo aumenta la sicurezza. Sull'hosting condiviso, dove più siti condividono lo stesso livello superiore, può causare conflitti – in caso di dubbio, verifica con il tuo host.
Come aiuta InspectWP con wp-config.php?
Durante il crawl, InspectWP verifica tra l'altro se file sensibili come wp-config.php o un backup wp-config.php.bak sono accessibili pubblicamente, se l'area di amministrazione è forzata su HTTPS e se l'output di debug trapela verso l'esterno. I risultati corrispondenti vengono contrassegnati come rischio di sicurezza nel report.