Disabilitare l'editor di temi e plugin con DISALLOW_FILE_EDIT

Nascoste in ogni installazione WordPress standard ci sono due pagine che quasi nessuno usa consapevolmente, ma che silenziosamente trasformano una password di amministratore rubata in una compromissione completa del server. Aspetto, Editor di file dei temi e Plugin, Editor di file dei plugin. Entrambe permettono a un amministratore di modificare i file PHP grezzi nell'installazione direttamente tramite il browser. Entrambe sono ancora attive per impostazione predefinita nel 2026. Ed entrambe sono completamente opzionali.

Questa guida spiega perché disabilitare gli editor è una delle modifiche di hardening con la più alta leva che puoi apportare a un sito WordPress, come appare la singola riga di configurazione, e cosa aspettarsi dopo (inclusi alcuni casi limite che sorprendono le persone).

Perché l'editor di codice integrato è un problema?

In una giornata normale, nessuno usa l'editor. Le modifiche al tema passano per un child theme o per la pipeline di deploy di uno sviluppatore. Le modifiche ai plugin avvengono in staging, non in produzione. L'editor è lì, inutilizzato, accessibile solo agli amministratori.

"Accessibile solo agli amministratori" è la parte che cede sotto attacco. Il modo in cui si svolge il tipico takeover WordPress non ha nulla a che fare con vulnerabilità a livello di codice nell'editor stesso. Appare così:

1. Una password di admin trapela. Phishing, riutilizzo di password da un servizio violato, un laptop di sviluppatore con malware, un plugin compromesso che esfiltra i cookie di sessione. Scegli uno dei soliti ingressi.
2. L'aggressore accede a /wp-admin come un vero amministratore. Dal punto di vista di WordPress, non c'è nulla di sbagliato, questo è un login legittimo.
3. L'aggressore va direttamente a Aspetto, Editor di file dei temi, apre functions.php e incolla una piccola backdoor PHP in cima.
4. Da quel momento in poi, ogni richiesta alla pagina iniziale del sito esegue il codice dell'aggressore. Hanno una shell esterna sul tuo server.

L'editor converte "password di admin rubata" in "webserver rubato". Senza l'editor, un aggressore che ruba una password di admin ha ancora i diritti di admin (il che è già abbastanza grave), ma deve prendere la strada più lenta e rumorosa caricando uno zip di plugin o tema malevolo per ottenere l'esecuzione del codice. Quel passaggio extra è un'opportunità extra per un plugin di sicurezza, uno scanner di integrità dei file o un WAF a livello di server di notare e bloccare il caricamento.

Il rapporto costo-beneficio è enormemente sbilanciato. L'editor viene usato qualche volta all'anno da una piccola minoranza di amministratori. Il rischio emerge per ogni sito che subisce una perdita di credenziali. Disabilitare l'editor è una di quelle modifiche dove il caso peggiore è "qualcuno deve usare SFTP per una modifica di cinque minuti" e il caso migliore è "il takeover non si escala mai da una perdita di password a una backdoor".

La soluzione: una singola riga in wp-config.php

WordPress ha una costante integrata esattamente per questo caso. Apri wp-config.php nella cartella root di WordPress e aggiungi la seguente riga, da qualche parte sopra il commento che recita /* That's all, stop editing! Happy publishing. */:

define('DISALLOW_FILE_EDIT', true);

Salva il file. È tutto. Il menu Editor di file dei temi sotto Aspetto e l'Editor di file dei plugin sotto Plugin scompaiono immediatamente per ogni utente, amministratori inclusi. Le pagine stesse restituiscono un errore di permessi se accedute direttamente tramite URL. Non c'è alcun plugin da installare, nessuna impostazione da mantenere, nessuna superficie di compatibilità di cui preoccuparsi. La costante fa parte del core di WordPress dalla versione 3.0 (rilasciata nel 2010) e non andrà da nessuna parte.

E se volessi bloccare anche gli upload di plugin e temi dall'admin?

WordPress ha una costante sorella più severa chiamata DISALLOW_FILE_MODS. Fa quello che fa DISALLOW_FILE_EDIT, più blocca gli upload di plugin, gli upload di temi e gli aggiornamenti del core dall'admin. Impostarla appare identico:

define('DISALLOW_FILE_MODS', true);

Questa è una modifica del comportamento molto più grande. Con DISALLOW_FILE_MODS attivo, non puoi più installare o aggiornare plugin, temi o il core di WordPress tramite l'admin normale. Tutti gli aggiornamenti devono venire da qualche altra parte: WP CLI, una pipeline di deploy, un upload SFTP o la dashboard centrale di un host gestito.

Per la maggior parte dei siti, è troppo restrittivo. Gli aggiornamenti sono il compito di sicurezza più importante su un sito WordPress, e renderli più difficili di solito significa che le persone li saltano. DISALLOW_FILE_MODS ha senso in due ambienti specifici: pipeline di deploy dove l'installazione di produzione è intesa come sola lettura, e ambienti ad alta sicurezza dove qualcuno è veramente responsabile per il push degli aggiornamenti dall'esterno. Per tutto il resto, il normale DISALLOW_FILE_EDIT colpisce il punto dolce di "enorme guadagno di sicurezza, nessun dolore operativo".

Cosa cambia per gli utenti dopo aver impostato questo?

Per il 99% degli amministratori sul 99% dei siti: nulla di visibile. I due elementi del menu sono spariti dalla dashboard. Nessuno se ne accorge, perché nessuno li usava.

I casi in cui qualcuno se ne accorge:

• Uno sviluppatore che modifica direttamente la produzione. Se hai qualcuno nel team che modifica abitualmente file di temi o plugin tramite il browser, deve passare a SFTP o a una pipeline di deploy. Quello è un cambiamento di flusso di lavoro, non un blocco. In effetti, questo è un buon momento per chiederti perché il codice di produzione viene mai modificato dal vivo.
• Plugin che si agganciano all'editor. Una manciata di plugin estende l'editor integrato con funzionalità extra. Caricheranno silenziosamente la loro UI quando l'editor è sparito. Il plugin stesso continua a funzionare di solito, solo l'integrazione dell'editor si rompe. Se dipendi da uno di questi, vedrai il buco durante i test.
• Codice personalizzato che usa i diritti edit_themes o edit_plugins. La costante rimuove questi diritti da ogni ruolo, amministratore incluso. Il codice che rende le funzionalità dipendenti esattamente da questi diritti si comporterà come se nessuno li avesse. Raro, ma vale la pena saperlo se mantieni un plugin personalizzato che esegue questo tipo di controllo di permessi.

Verificare che sia attivo

1. Accedi a WordPress come amministratore.
2. Apri il menu Aspetto nella sidebar dell'admin. L'elemento "Editor di file dei temi" dovrebbe mancare.
3. Apri il menu Plugin. L'elemento "Editor di file dei plugin" dovrebbe mancare.
4. Per un controllo extra, naviga direttamente a https://tuodominio.it/wp-admin/theme-editor.php. WordPress dovrebbe reindirizzarti a una pagina che dice "Spiacente, non hai il permesso di modificare i file dei temi".
5. Esegui una nuova scansione InspectWP. Il controllo "editor di file abilitato" nella sezione sicurezza dovrebbe diventare verde.

Se gli elementi del menu sono ancora lì dopo aver salvato wp-config.php, le ragioni più comuni sono: cache di oggetti (svuotala), cache opcode come OPcache (potrebbe volerci un momento per riprendere il nuovo file, oppure puoi riavviare PHP FPM), la modifica del file è finita in un wp-config.php sbagliato in una cartella superiore, o la costante è stata impostata più avanti nel file da qualcos'altro e la tua riga viene sovrascritta. Apri wp-config.php dall'inizio e cerca DISALLOW_FILE_EDIT; dovresti vedere la tua riga e nient'altro che la reimposti dopo.

Cosa fa e cosa non fa questa soluzione

Vale la pena essere chiari su quale tipo di attacco DISALLOW_FILE_EDIT ferma e cosa lascia intatto. Ferma il percorso specifico in cui un aggressore usa un login admin rubato per scrivere PHP nei file di tema o plugin tramite il browser. Non ferma:

• Un aggressore che carica uno zip di plugin o tema malevolo dall'admin (usa DISALLOW_FILE_MODS per questo, con i compromessi descritti sopra, o limita i diritti per gli upload di plugin).
• Un aggressore che sfrutta una vulnerabilità a livello di codice in un plugin per scrivere file. Per questo, il plugin stesso deve essere patchato.
• Un aggressore che ha accesso SFTP o shell. A quel punto, lo strato WordPress viene completamente aggirato.

DISALLOW_FILE_EDIT è uno strato di difesa, non una strategia completa. Si abbina naturalmente a password admin forti, autenticazione a due fattori sugli account admin e un plugin di sicurezza che monitora modifiche inaspettate ai file. La combinazione rimuove il percorso di takeover più facile e rende i percorsi più difficili abbastanza rumorosi da notare.

Una riga in wp-config.php, nessun plugin, nessuna manutenzione, nessuna superficie di compatibilità. Se non fai nient'altro questo mese per un sito WordPress, fai questo.