Come proteggere /wp-admin/install.php in WordPress

Ogni installazione WordPress viene fornita con un file chiamato wp-admin/install.php. Su un sito sano è solitamente innocuo. WordPress nota che il sito è già configurato e restituisce una breve pagina "Already Installed". Ma c'è un caso limite che molti proprietari di siti sottovalutano. Nel momento in cui qualcosa va storto con il database, lo stesso file si trasforma in un wizard di installazione pienamente funzionante. Un aggressore che ci si imbatte al momento giusto può reinstallare WordPress sopra il tuo dominio, farlo puntare a un database che controlla e andarsene con un takeover completo.

Questa guida spiega quando install.php è effettivamente pericoloso, quali plugin di sicurezza coprono davvero questo caso (non tutti, nonostante quello che suggerisce il loro marketing) e come bloccare correttamente il file. Questo include anche la situazione meno confortevole in cui sei su uno shared host senza accesso alla configurazione del server.

Quando install.php è effettivamente un problema?

Se visiti https://tuodominio.com/wp-admin/install.php su un sito sano, WordPress controlla se la tabella wp_options contiene già un siteurl. Se sì, mostra la schermata "Already Installed" e lì la storia finisce. Nessun form, nessuna azione, nessun takeover.

Il problema inizia nel momento in cui WordPress non può leggere quel valore. Scenari tipici:

• Le credenziali del database in wp-config.php si sono rotte (password sbagliata dopo una migrazione dell'host, nome DB digitato male).
• Qualcuno ha eliminato o svuotato la tabella wp_options, sia per errore durante una migrazione sia intenzionalmente tramite un'SQL injection in un plugin vulnerabile.
• Una clonazione di staging fallita ha lasciato il filesystem al suo posto, ma il database vuoto.
• L'utente del database ha perso i diritti su tabelle specifiche.

In tutti questi casi, il wizard di installazione diventa disponibile per chiunque su Internet. Chi lo raggiunge per primo può scegliere il nome utente, la password e l'email dell'admin e di fatto possiede il dominio. Ecco perché questo controllo esiste in InspectWP, anche se il file è "normale" su ogni installazione WordPress.

Quali plugin di sicurezza possono effettivamente proteggere install.php?

Questa è la parte su cui le persone inciampano, quindi vale la pena essere precisi. La maggior parte delle persone presume che ogni plugin di sicurezza WordPress copra automaticamente install.php. È mezza verità. La risposta dipende interamente da come si carica il plugin.

Un normale plugin WordPress si avvia all'interno di WordPress. Ha bisogno del database per partire. Se il tuo DB è rotto o vuoto (che è l'unico scenario realistico in cui install.php diventa pericoloso), WordPress non si avvia mai abbastanza da caricare il plugin. La richiesta finisce direttamente su install.php e PHP renderizza allegramente il wizard di installazione. I plugin di sicurezza che funzionano come plugin normali non possono per definizione aiutare in quella situazione.

Tuttavia, diversi plugin usano un meccanismo PHP chiamato auto_prepend_file. Quell'impostazione dice a PHP di eseguire un file specifico prima di ogni altro script PHP sul server. Quando un plugin di sicurezza si registra in questo modo, viene eseguito prima di wp-config.php, prima che la connessione al database venga nemmeno tentata, e prima di install.php. Ha i propri file di configurazione e, dove necessario, la propria connessione al database. Un'installazione WordPress rotta non lo influenza.

Plugin che supportano questa modalità (e che quindi possono proteggere install.php anche quando il database WordPress non funziona):

• Wordfence in modalità Extended Protection (a volte chiamata Optimized Mode). Questa non è l'impostazione predefinita dopo l'installazione. Devi abilitarla esplicitamente nelle impostazioni del firewall di Wordfence. Una volta attivo, un file chiamato wordfence-waf.php viene posizionato nella root di WordPress e registrato tramite .htaccess, .user.ini o php.ini.
• NinjaFirewall (WP Edition). Usa auto_prepend_file come modalità predefinita. È configurato così al momento dell'installazione, nessun interruttore extra necessario.
• NinjaFirewall (Pro / Full WAF). Stesso meccanismo, ma registrato a livello di server. Funziona completamente al di fuori di WordPress.
• BitFire Security. Supporta una modalità "Always On Protection", anch'essa basata su auto_prepend_file. Comportamento simile a Wordfence Extended Protection.
• Shield Security (ShieldPRO). Carica anch'esso tramite auto_prepend_file, anche se ha un approccio più conservativo e non modifica direttamente .htaccess.
• MalCare. Usa auto_prepend_file come parte della sua installazione WAF.

Plugin che non possono bloccare install.php quando WordPress è rotto, perché funzionano come normali plugin WordPress:

• Wordfence nella modalità Basic Mode predefinita (prima di abilitare Extended Protection).
• Solid Security (ex iThemes Security). Non fornisce un WAF che viene eseguito prima di WordPress.
• All-In-One WP Security & Firewall. Bravo nell'hardening di file e login, ma viene eseguito all'interno di WordPress.
• La maggior parte dei firewall basati su plugin che non si affidano a auto_prepend_file.

Una conseguenza pratica: se usi Wordfence, vai su Wordfence, Firewall, Manage WAF e controlla se il messaggio dice "Optimized" o "Extended Protection Enabled". Se dice ancora Basic Mode, il wizard di ottimizzazione ti guida nell'impostazione di auto_prepend_file per il tuo server. Questa singola modifica è ciò che trasforma Wordfence da un plugin reattivo in un vero firewall pre-WordPress.

Un'avvertenza per entrambi i percorsi. Il meccanismo richiede che il tuo host permetta effettivamente auto_prepend_file tramite .htaccess, .user.ini o php.ini. Sulla maggior parte degli shared host funziona out of the box. Su alcuni host gestiti bloccati, l'impostazione è limitata e il wizard di ottimizzazione fallirà silenziosamente o mostrerà un avviso. In quel caso, sei di nuovo al webserver-rule approach descritto sotto.

Opzione 1: bloccare install.php tramite .htaccess (Apache)

Se il tuo host esegue Apache (cosa che vale per la maggior parte dei provider di shared hosting come IONOS, Strato, All-Inkl, Hostinger, DomainFactory, SiteGround, Bluehost), puoi aggiungere il seguente blocco al file .htaccess nella directory root di WordPress:

<Files "install.php">
  Require all denied
</Files>

Questo funziona su Apache 2.4 e superiori, che è stato usato da praticamente ogni host per anni. Se sei su qualcosa di più vecchio (Apache 2.2), usa invece la vecchia sintassi:

<Files "install.php">
  Order allow,deny
  Deny from all
</Files>

Posiziona lo snippet sopra il marker # BEGIN WordPress, in modo che la gestione automatica delle rewrite di WordPress non lo tocchi durante gli aggiornamenti.

Dopo aver salvato il file, visita https://tuodominio.com/wp-admin/install.php in una finestra del browser privata. Dovresti vedere una risposta 403 Forbidden. Se vedi ancora la pagina "Already Installed", le sovrascritture .htaccess sono disabilitate sul tuo host. Vai all'Opzione 3.

Opzione 2: bloccare install.php tramite nginx

Su nginx non c'è .htaccess. Se gestisci il tuo server (VPS, dedicato o un host flessibile come Hetzner Cloud), aggiungi questo all'interno del blocco server del tuo sito:

location = /wp-admin/install.php {
  deny all;
  return 403;
}

Ricarica nginx con sudo nginx -t && sudo systemctl reload nginx e testa con curl -I https://tuodominio.com/wp-admin/install.php. Dovresti ottenere un 403.

Alcuni host gestiti che usano nginx sotto il cofano (come Raidboxes, Kinsta, WP Engine) forniscono già regole di questo tipo. Vale la pena controllare la documentazione del tuo host o aprire un ticket di supporto. La risposta è solitamente "già coperto" o aggiungono la regola per te.

Opzione 3: shared hosting senza sovrascritture Apache

Se sei su uno shared nginx host e .htaccess viene ignorato, hai meno opzioni, ma non sei bloccato. In ordine di preferenza:

1. Installa uno dei firewall pre-WordPress menzionati sopra. Su shared host dove auto_prepend_file è permesso, un plugin come NinjaFirewall o Wordfence in modalità Extended Protection ti dà la stessa protezione di una regola server, senza toccare alcuna configurazione del server. Questo è spesso il percorso più pragmatico.
2. Chiedi al tuo host. La maggior parte degli host WordPress gestiti aggiungerà una regola a livello di server per te su richiesta. Ci vogliono cinque minuti e lo fanno di routine.
3. Sostituisci il contenuto del file. Puoi aprire wp-admin/install.php tramite SFTP e sostituire l'intero file con una singola riga:

   <?php // intentionally disabled, see install.php.bak

   Mantieni un backup dell'originale (install.php.bak) al di fuori della webroot pubblica nel caso in cui tu debba mai reinstallare legittimamente. Lo svantaggio: gli aggiornamenti del core di WordPress ripristineranno il file originale, quindi dovrai riapplicare la modifica dopo ogni aggiornamento importante. Un piccolo plugin must-use può automatizzare questo (vedi lo snippet di codice correlato).
4. Nega l'accesso tramite permessi dei file. Cambiare la modalità del file a 000 tramite SFTP blocca anche l'accesso sulla maggior parte degli host. Stesso avviso: gli aggiornamenti del core lo resetteranno.

Cosa ne è di rinominare o eliminare install.php?

Tecnicamente puoi eliminare completamente install.php. WordPress non ne ha bisogno per il funzionamento normale. Viene usato solo durante l'installazione iniziale e per alcune routine di upgrade interne. Il problema è che il file viene ripristinato a ogni aggiornamento del core di WordPress, quindi l'eliminazione non è una soluzione permanente. Viene anche occasionalmente referenziato dal processo di upgrade automatico, quindi potresti vedere avvisi nel tuo log degli errori se manca.

Rinominare è ancora peggio. WordPress non trova il file sotto il suo nuovo nome, ma ricreerà allegramente l'originale durante il prossimo aggiornamento. Finisci con due copie.

Bloccare l'accesso a livello di webserver, o tramite un firewall pre-WordPress, è quasi sempre la risposta migliore.

Come verificare la tua installazione

Dopo aver applicato una delle opzioni sopra:

1. Apri https://tuodominio.com/wp-admin/install.php in una finestra privata o in incognito.
2. Dovresti vedere una pagina 403 Forbidden (o 404 se hai eliminato il file, o la pagina di blocco personalizzata del firewall se hai seguito la strada del plugin).
3. Se vedi la pagina "Already Installed" o, molto peggio, un vero form di installazione, la regola non è attiva. Ricontrolla il percorso del file, cancella eventuali cache (Cloudflare, Varnish, cache delle pagine a livello di server) e riprova.
4. Esegui una nuova scansione InspectWP. Il controllo "install.php esposto" nella sezione WordPress dovrebbe diventare verde.

Controlli correlati che vale la pena eseguire

Mentre stai bloccando le cose, vale la pena applicare lo stesso tipo di blocco a livello di webserver (o regola di firewall pre-WordPress) a un paio di altri endpoint sensibili: xmlrpc.php (a meno che tu non lo stia usando attivamente), wp-config.php.bak, .git/, .env e qualsiasi file phpinfo.php che uno sviluppatore potrebbe aver lasciato. InspectWP li segnala tutti automaticamente nella sezione sicurezza.

Il caso install.php è un buon esempio di defense in depth. WordPress si protegge da solo, un plugin di sicurezza correttamente configurato aggiunge un altro livello e una regola del webserver copre lo scenario in cui entrambi possono fallire. Scegli qualsiasi combinazione si adatti al tuo host. Cinque righe di configurazione, o un interruttore in un plugin firewall, sono sufficienti per chiudere il buco per sempre.