Sicurezza WordPress: come proteggere e blindare wp-config.php

Il file wp-config.php rappresenta il cuore nevralgico della sicurezza in WordPress: custodisce in chiaro le credenziali del database MySQL, le chiavi univoche di autenticazione (AUTH_KEY, SECURE_AUTH_KEY) e il prefisso delle tabelle.

Lasciare questo file con i permessi standard 644 (lettura globale per qualsiasi utente del sistema) espone l’infrastruttura a rischi sistemici critici, in particolare in ambienti shared hosting con permessi di processo permissivi. Una corretta strategia di hardening multilivello richiede interventi precisi su permessi del file system, isolamento architetturale e direttive a livello web server.

1. Restrizione dei permessi del file system (CHMOD)

In un’installazione standard, i permessi di default permettono a qualsiasi processo locale di leggere il contenuto del file. Su server dedicati o VPS con stack LEMP/LAMP isolato, la configurazione corretta consiste nel bloccare qualsiasi accesso in scrittura e consentire la sola lettura all’utente del processo PHP-FPM o al web server.

A seconda della configurazione dell’utente web (www-data, nginx o utente dedicato del pool):

# Permesso consigliato: sola lettura per il proprietario (es. utente pool PHP-FPM)
chmod 400 wp-config.php

# In alternativa, se il server richiede l'accesso tramite gruppo di sistema:
chmod 440 wp-config.php

In questo modo si impedisce l’iniezione accidentale di codice malevolo nel file anche in caso di compromissione parziale di un plugin vulnerabile.

2. Spostamento del file sopra la Root pubblica

WordPress supporta nativamente una funzionalità architetturale spesso trascurata: se wp-config.php non viene trovato nella directory principale del sito, il core cerca automaticamente una cartella sopra.

Se il tuo sito si trova nel percorso standard /var/www/html/public/, puoi spostare fisicamente il file al livello superiore:

mv /var/www/html/public/wp-config.php /var/www/html/wp-config.php

Questa contromisura isola le credenziali all’esterno della cartella servita pubblicamente, rendendole inaccessibili a qualsiasi richiesta HTTP diretta anche in caso di temporaneo crash del modulo PHP del web server.

Nota: Se utilizzi hosting gestiti o ambienti con tool di staging automatico che vincolano i percorsi fisici, mantieni il file nella root e affidati alla blindatura via web server illustrata al punto successivo.

3. Blocco accessi a livello Web Server (NGINX e Apache)

Affidarsi unicamente all’interprete PHP per non mostrare il codice sorgente è un errore. L’infrastruttura deve intercettare e bloccare qualsiasi tentativo di richiesta verso wp-config.php direttamente sul perimetro.

Su NGINX: Inserisci la direttiva all’interno del blocco server:

location = /wp-config.php {
    deny all;
    access_log off;
    log_not_found off;
    return 404;
}

Nota sistemistica: Restituire un codice HTTP 404 Not Found anziché un 403 Forbidden evita di confermare a scanner e botnet la presenza effettiva del file sul percorso canonico.

Su Apache (.htaccess): Inserisci la regola in cima al file, prima dei rewrite di WordPress:

<Files wp-config.php>
    Require all denied
</Files>

4. Disabilitazione dell’editor interno e dell’installazione temi

Se un malintenzionato o una vulnerabilità XSS permette l’accesso non autorizzato alla bacheca amministrativa di WordPress, la prima azione eseguita è l’iniezione di webshell tramite l’editor integrato di temi e plugin.

Aggiungi questa costante all’interno di wp-config.php, prima della riga che dichiara "That's all, stop editing!":

define( 'DISALLOW_FILE_EDIT', true );

Questa singola direttiva rimuove completamente l’editor di codice dalla bacheca, impedendo modifiche arbitrarie a file PHP o CSS via interfaccia web.