Hardening di wp-config.php: 10 impostazioni da controllare

wp-config.php contiene la password del database, le chiavi che firmano ogni cookie di accesso e gli interruttori che decidono se gli errori vengono mostrati ai visitatori. La maggior parte dei titolari di siti non l'ha mai aperto. Questa guida all'hardening di wp-config.php è un audit in dieci punti su quell'unico file. Per ogni controllo trovate la riga esatta, il valore da usare in produzione, il modo per verificarlo e ciò da cui l'impostazione non protegge.

Cosa controlla wp-config.php e come modificarlo senza schermata bianca

Il file contiene tre tipi di elementi. Primo, le credenziali del database. Secondo, otto chiavi e salt di sicurezza. Terzo, le costanti che modificano il comportamento di WordPress. Chi riesce a leggere il file può accedere al database. Chi riesce a scriverci può eseguire codice a ogni caricamento di pagina.

È anche il file più facile da rompere. Un solo punto e virgola mancante produce una schermata bianca o un errore fatale per tutti i visitatori. Conviene seguire sempre questa procedura:

1. Scaricare sul proprio computer una copia del file attuale.
2. Modificare via SFTP o SSH, non con un file manager nel browser né con un plugin.
3. Se si dispone di accesso shell, eseguire php -l wp-config.php. Deve restituire "No syntax errors detected".
4. Ricaricare il front end e /wp-admin/ in una finestra privata.
5. Se qualcosa non funziona, ricaricare sul server la propria copia e correggere la modifica con calma.
6. Se tutto funziona, eliminare dal server le copie temporanee create (come wp-config.php.bak). La copia sul proprio computer va conservata.

Anche la posizione conta. Verso la fine del file si trova il commento /* That's all, stop editing! Happy publishing. */, seguito da require_once ABSPATH . 'wp-settings.php';. Le costanti definite dopo quella riga arrivano troppo tardi per la maggior parte delle impostazioni. Ogni nuovo define() va inserito sopra il commento. Il riferimento ufficiale è la pagina su wp-config.php nella documentazione per sviluppatori di WordPress.

Segreti: credenziali del database e chiavi e salt di sicurezza univoci

Controllo 1: credenziali del database. DB_USER dovrebbe essere un utente del database che esiste solo per questo sito, con una password lunga e casuale. Se tre siti condividono lo stesso utente, la fuga di dati da uno li espone tutti e tre. Non riutilizzare mai qui la password del pannello di hosting. Questo controllo non serve se l'attaccante esegue già codice sul server, perché in quel caso può comunque leggere il file.

Controllo 2: chiavi e salt. Sono otto: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY e le quattro costanti _SALT corrispondenti. Devono essere lunghe, casuali e uniche per questo sito. Se anche una sola riporta ancora put your unique phrase here, va sostituita oggi stesso. Un nuovo set si genera su api.wordpress.org/secret-key/1.1/salt/ e si incolla al posto del vecchio blocco. Con WP-CLI basta un comando:

wp config shuffle-salts

I salt vanno rigenerati dopo un attacco, quando un amministratore o un'agenzia con accesso ai file cessa la collaborazione, o se il file è mai stato esposto.

Dopo una compromissione, la rotazione di questi segreti è solo uno dei passaggi di una bonifica più ampia. L'ordine completo è descritto in rimozione del malware da WordPress.

Impostazioni di debug in produzione: WP_DEBUG, WP_DEBUG_DISPLAY e WP_DEBUG_LOG

Controllo 3: WP_DEBUG. Su un sito online deve essere false. Gli errori visualizzati rivelano percorsi del server, nomi dei plugin e a volte frammenti di query. Un attaccante può usarli per scegliere il bersaglio.

define( 'WP_DEBUG', false );

Impostare WP_DEBUG su false non disattiva la direttiva display_errors di PHP. Se l'host la lascia attiva, gli avvisi possono comunque comparire nella pagina. Occorre chiederlo all'host o controllare la configurazione PHP, se si gestisce il server in proprio.

Controllo 4: se servono i log, nasconderli e spostarli. A volte bisogna fare debug in produzione. In tal caso, mai mostrare gli errori nella pagina e non usare la posizione predefinita del log. WP_DEBUG_LOG impostato su true scrive in wp-content/debug.log, che spesso è scaricabile pubblicamente. Meglio indicare un percorso fuori dalla radice web:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/example/logs/wp-debug.log' );
@ini_set( 'display_errors', '0' );

La directory deve esistere ed essere scrivibile dall'utente PHP. Poi si verifica che nessun vecchio log sia ancora pubblico:

curl -I https://example.com/wp-content/debug.log

Il risultato corretto è 403 o 404. Un 200 significa che chiunque può leggere il log. Eliminarlo.

I log contengono spesso indirizzi e-mail, indirizzi IP e dati inviati tramite moduli, quindi sono dati personali. Al termine, il logging va disattivato e i vecchi file di log eliminati o ruotati. I dettagli su ciascuna costante sono nella documentazione sul debug di WordPress.

HTTPS e ambiente: FORCE_SSL_ADMIN e WP_ENVIRONMENT_TYPE

Controllo 5: FORCE_SSL_ADMIN. Mantiene la pagina di login, la dashboard e i cookie di amministrazione su HTTPS:

define( 'FORCE_SSL_ADMIN', true );

Riguarda solo l'area di amministrazione e gli accessi. Non sostituisce un reindirizzamento da HTTP a HTTPS su tutto il sito a livello di server e non è HSTS.

Controllo 6: WP_ENVIRONMENT_TYPE. Questa impostazione indica a WordPress e ai plugin che tipo di sito stanno eseguendo. I valori validi sono production, staging, development e local. Il valore predefinito è production.

define( 'WP_ENVIRONMENT_TYPE', 'production' );

L'impostazione ha effetti concreti. Nel core, un ambiente development attiva WP_DEBUG se non lo si è definito esplicitamente. Alcuni plugin e host leggono il valore per bloccare l'invio di e-mail o per modificare la cache sui siti non di produzione. Il punto più importante, però, è l'etichettatura. Una copia di staging contiene di solito un duplicato completo dei dati reali di clienti e ordini. Va contrassegnata come staging e protetta con autenticazione HTTP o con una restrizione per indirizzo IP. A fine progetto va eliminata. Un sottodominio di staging dimenticato, con il database clienti dell'anno scorso, è una fonte frequente di fughe di dati.

Editor di file e modifica dei file: DISALLOW_FILE_EDIT e DISALLOW_FILE_MODS

Controllo 7: aggiungere questa riga a ogni sito:

define( 'DISALLOW_FILE_EDIT', true );

Rimuove dalla dashboard gli editor di file dei temi e dei plugin. Un accesso amministratore rubato non può così essere trasformato in esecuzione di codice con pochi clic. Non ferma però un attaccante in grado di caricare un plugin.

Controllo 8: DISALLOW_FILE_MODS va oltre. Blocca anche l'installazione e l'aggiornamento di plugin e temi dalla dashboard e disattiva gli aggiornamenti automatici in background. Va attivato solo dopo aver predisposto un altro canale di aggiornamento, come WP-CLI, una pipeline di deployment o aggiornamenti gestiti dall'host. Altrimenti il sito resta congelato sulle versioni vulnerabili di oggi. Entrambe le impostazioni e il flusso di aggiornamento sono trattati in DISALLOW_FILE_EDIT: disattivare l'editor di file di WordPress.

Permessi dei file, posizione e copie dimenticate di wp-config.php

Controllo 9: permessi. Il valore corretto dipende dall'utente con cui gira PHP:

• 400 o 440: da usare quando il proprietario del file è un utente diverso da quello di PHP. Il gruppo deve includere l'utente PHP, che avrà così solo accesso in lettura.
• 600: da usare quando PHP gira come proprietario del file, situazione comune con i pool PHP-FPM per account.

Sull'hosting condiviso è meglio evitare 644, perché altri account sullo stesso server potrebbero riuscire a leggere il file. Mai usare 777.

ls -l wp-config.php
chmod 440 wp-config.php

Per proprietà e permessi nel resto dell'installazione, si veda web shell e permessi dei file.

Spostare il file una directory sopra la radice web è consentito. WordPress lo cerca automaticamente lì quando la cartella superiore non contiene un'installazione WordPress propria. Il vantaggio è modesto: conta solo se PHP smette di essere eseguito e il server restituisce i file .php come testo semplice. Se è facile da fare, va bene, ma non lo si consideri una vera soluzione.

Controllo 10: copie dimenticate. È il rischio più grande e più frequente. File come wp-config.php.bak, wp-config.php.old, wp-config.php.save, wp-config.php~ o un file di swap dell'editor come .wp-config.php.swp non terminano con .php. Il server web può consegnarli come testo semplice, password del database inclusa. Per trovarli:

find /var/www/example -name '*wp-config*' -type f

Devono restare solo wp-config.php e l'innocuo wp-config-sample.php. Tutto il resto va eliminato. Rinominare i file non serve. Se una copia era raggiungibile via web, vanno ruotati anche la password del database e i salt.

Il controllo in 10 punti di wp-config.php in una tabella

Un esito pulito qui non dice nulla su plugin vulnerabili, password di amministratore deboli o una versione di PHP obsoleta. Per questi aspetti serve la checklist di sicurezza di WordPress.

Il plugin Security Audit & Compliance di secaudit.eu include una scansione di hardening e configurazione e verifica la presenza di segreti e file esposti, come i backup dimenticati. Offre inoltre un interruttore opzionale per disattivare gli editor di file della dashboard → secaudit.eu

Il prossimo passo: scaricare subito una copia di wp-config.php ed eseguire il comando find per cercare le copie dimenticate. Bastano due minuti e si copre l'esposizione più spesso trascurata.

FAQ

Cambiare i salt rompe il sito?

No. Contenuti, impostazioni e password restano invariati. Tutti gli utenti connessi vengono disconnessi e devono accedere di nuovo, quindi conviene avvisare prima redattori e clienti dello shop.

Conviene cambiare il prefisso delle tabelle su un sito esistente?

Di solito no. Un prefisso personalizzato aggiunge poca protezione reale e cambiarlo su un sito online significa rinominare le tabelle e aggiornare le voci nelle tabelle options e usermeta. Un errore può bloccare l'accesso a tutti gli utenti. Meglio lasciarlo, a meno che non si stia comunque ricostruendo il sito.

Un plugin può gestire wp-config.php al posto mio?

Alcuni possono. Tuttavia un plugin in grado di scrivere in wp-config.php è esso stesso un rischio: una sua vulnerabilità diventa accesso in scrittura al file più sensibile. Meglio le modifiche manuali via SFTP o SSH, conservando una copia dell'ultima versione funzionante.