DISALLOW_FILE_EDIT: disattivare l'editor file di WordPress

Basta una riga in wp-config.php: define( 'DISALLOW_FILE_EDIT', true );. Questa riga elimina dalla bacheca l'editor dei file del tema e quello dei plugin. Richiede due minuti e non incide sugli aggiornamenti. Toglie inoltre la scorciatoia più breve tra una password di amministratore rubata e l'esecuzione di codice sul vostro server.

Questo articolo spiega perché DISALLOW_FILE_EDIT è importante, come impostarlo in modo sicuro e che cosa non impedisce. Chiarisce anche quando vale la pena affrontare il lavoro aggiuntivo richiesto dal più restrittivo DISALLOW_FILE_MODS.

Perché DISALLOW_FILE_EDIT conta: dall'accesso admin al codice in esecuzione

WordPress include due editor di codice integrati. L'editor dei file del tema si trova sotto Aspetto per i temi classici o sotto Strumenti per i temi a blocchi. L'editor dei file dei plugin si trova sotto Plugin per i temi classici, oppure anch'esso sotto Strumenti per i temi a blocchi. Entrambi permettono agli amministratori (in multisite, ai super amministratori) di modificare file PHP dal browser e di salvarli; il server esegue quel codice al caricamento successivo della pagina.

Un accesso da amministratore equivale quindi, di fatto, a un accesso shell. Chi dispone di una password admin sottratta con phishing, riutilizzata o indovinata a forza bruta può aprire functions.php e incollarvi una backdoor. Può anche aggiungere un reindirizzamento nascosto per i visitatori che arrivano dai motori di ricerca, oppure iniettare uno skimmer di carte in un template del checkout. Non servono né FTP né accesso all'hosting: basta il login.

La maggior parte dei siti in produzione non ha mai bisogno di modificare il codice dal browser. Gli sviluppatori lavorano in un editor di codice, su un ambiente di staging o tramite il controllo di versione. Modificare PHP dal vivo in un campo di testo significa nessun annullamento, nessuna revisione, e un solo errore di sintassi può mettere offline il sito. Per un sito aziendale in produzione l'editor aggiunge rischio e poco altro.

Proteggere il login è un compito distinto, trattato nella nostra guida all'autenticazione a due fattori per gli amministratori WordPress. DISALLOW_FILE_EDIT limita ciò che un login rubato permette di fare.

Come aggiungere DISALLOW_FILE_EDIT a wp-config.php

1. Scaricate una copia di wp-config.php e conservatela come backup. Su molti hosting il file si trova nella directory principale di WordPress; in alcune configurazioni è una directory più in alto.
2. Aprite il file via SFTP o con il file manager del vostro hosting. Non usate un plugin di WordPress per questa operazione.
3. Cercate DISALLOW_FILE_EDIT nel file. Se è già definita, modificate quella riga invece di aggiungerne una seconda: definire due volte una costante genera un avviso PHP.
4. Inserite la riga sopra il commento che inizia con /* That's all, stop editing!. Deve venire prima del caricamento di wp-settings.php.
5. Salvate, caricate il file e ricaricate la bacheca.

/* Disattiva gli editor di temi e plugin nella bacheca */
define( 'DISALLOW_FILE_EDIT', true );

/* That's all, stop editing! Happy publishing. */

Poi verificate il risultato. Le voci di menu Editor del file del tema e Editor del file dei plugin devono essere scomparse. Aprendo direttamente /wp-admin/theme-editor.php dovreste ottenere un errore di autorizzazioni invece dell'editor.

Questa costante non si può riattivare dalla bacheca, ed è esattamente lo scopo. Chi vuole riavere l'editor deve avere accesso ai file del server, non soltanto una password admin. L'impostazione vale per l'intera installazione e, in multisite, per tutti i siti della rete. La documentazione ufficiale su wp-config.php la elenca insieme alle altre costanti di configurazione.

Se non avete accesso SFTP o a un file manager, il plugin Security Audit & Compliance di secaudit.eu offre un interruttore opzionale che disattiva gli editor di file della bacheca.

Da cosa non protegge la disattivazione dell'editor file

DISALLOW_FILE_EDIT elimina la via più semplice. Non rende innocuo un account amministratore. Un amministratore, o un malintenzionato che usa quell'account, può ancora:

• caricare lo zip di un plugin o di un tema con codice malevolo, da Plugin → Aggiungi nuovo plugin o da Aspetto → Temi
• creare nuovi account amministratore, cambiare l'email dell'admin o reimpostare le password di altri utenti
• modificare impostazioni come l'URL del sito, la registrazione degli utenti o il ruolo predefinito
• esportare dati di utenti e ordini

Chi ha accesso a FTP, SSH, pannello dell'hosting o database aggira del tutto WordPress, e nessuna costante di wp-config.php lo ferma. La costante non serve nemmeno contro i plugin vulnerabili sfruttabili senza alcun login: è un problema a parte, con rimedi propri, trattato nella nostra guida ai plugin WordPress vulnerabili.

Considerate DISALLOW_FILE_EDIT come uno strato di protezione. Costa poco e vale la pena averlo, ma non risolve né un login debole né un plugin non aggiornato.

Plugin di file manager e di snippet di codice: l'editor sotto un altro nome

Diversi tipi di plugin riportano lo stesso rischio, e DISALLOW_FILE_EDIT non li copre:

• plugin di file manager che permettono di sfogliare, modificare e caricare file dalla bacheca
• gestori di snippet di codice che memorizzano PHP e lo eseguono a ogni richiesta
• campi "inserisci codice nell'header/footer" che accettano script o PHP
• opzioni del tema o del page builder con un riquadro "codice personalizzato"

Se uno di questi è attivo, chi ha un login admin dispone ancora di un editor di codice.

Cominciate facendo l'elenco di ciò che avete. Passate in rassegna Plugin → Plugin installati e le opzioni del tema, e annotate tutto ciò che può modificare file o eseguire codice personalizzato. Poi intervenite per tipo:

• File manager: eliminateli appena terminata l'operazione una tantum. Disattivarli non basta, perché il codice resta sul server e può avere a sua volta delle vulnerabilità.
• Snippet davvero necessari: spostateli in un piccolo plugin personalizzato o in un child theme e teneteli sotto controllo di versione. Le modifiche passano così dal normale processo di rilascio e non dal browser.
• Gestori di snippet che mantenete: verificate quali ruoli possono creare o modificare gli snippet e limitate l'accesso al minor numero possibile di persone.

DISALLOW_FILE_MODS: un blocco più forte, con compromessi concreti

define( 'DISALLOW_FILE_MODS', true ); va oltre. Blocca dalla bacheca l'installazione, l'aggiornamento e l'eliminazione di plugin e temi, e disattiva anche gli aggiornamenti automatici in background di WordPress. Chiude così la via del caricamento di file zip che DISALLOW_FILE_EDIT lascia aperta.

Il prezzo è che nulla si aggiorna più da solo. Se nessuno esegue gli aggiornamenti in altro modo, il sito accumula lentamente ritardo sulle correzioni di sicurezza. Anche le consuete notifiche di aggiornamento spariscono dalla bacheca. Solo Salute del sito segnala che gli aggiornamenti in background sono disattivati, perciò la lacuna passa facilmente inosservata.

Predisporre il canale di aggiornamento prima di attivare DISALLOW_FILE_MODS

Scegliete uno di questi approcci e rendetelo una routine:

• WP-CLI sul server. Eseguite gli aggiornamenti da riga di comando, a mano o con un job pianificato:

wp core update
wp plugin update --all
wp theme update --all

• Deployment con Git o Composer. Le versioni di plugin e temi sono definite nel repository e una pipeline compila e distribuisce il sito. Gli aggiornamenti diventano commit che si possono rivedere e annullare.
• Strumenti di aggiornamento dell'hosting gestito. Alcuni provider eseguono gli aggiornamenti per voi, spesso con un backup o un controllo visivo preliminare. Verificate con precisione che cosa è coperto e se i plugin premium sono inclusi.

Provate il metodo scelto su una copia di staging in cui DISALLOW_FILE_MODS sia già attiva. Ciò che funziona dipende dalla configurazione del vostro server, quindi accertatevene prima di toccare la produzione.

Pianificate gli aggiornamenti con un cron job o con un trigger della pipeline, e controllate che il job giri davvero. Un job che fallisce in silenzio non vale più di nessun job. Tenete un registro di che cosa è stato aggiornato e quando: è una prova utile di "misure tecniche e organizzative adeguate" ai sensi dell'articolo 32 del GDPR.

La rapidità conta. Patchstack, un fornitore di soluzioni di sicurezza, riporta nel suo State of WordPress Security in 2026 che il tempo mediano ponderato prima dello sfruttamento di massa è stato di 5 ore per le vulnerabilità più sfruttate. Un giro di aggiornamenti manuale una volta al mese non regge a quel ritmo.

Verificare che il blocco sia ancora in vigore

Durante migrazioni, cambi di hosting e debug "temporanei" le costanti si perdono facilmente. Controllatele ogni tanto:

grep -n DISALLOW_FILE wp-config.php
wp config get DISALLOW_FILE_EDIT

Il primo comando mostra ogni riga corrispondente con il relativo numero. Il secondo mostra il valore che WP-CLI legge dalla configurazione. Eseguite di nuovo entrambi dopo ogni passaggio a un nuovo server o hosting. Tenete d'occhio anche le modifiche inattese ai file PHP del tema e dei plugin: con il blocco attivo, una modifica del genere significa che qualcuno è entrato per un'altra strada.

Se scoprite che l'editor è già stato usato contro di voi, non si tratta più di hardening ma di gestione dell'incidente. Prima di toccare altro leggete le nostre guide su come individuare le web shell e sulla rimozione di malware da WordPress.

Il plugin di audit di secaudit.eu controlla le impostazioni di hardening e di configurazione, editor file compreso. Verifica inoltre l'integrità dei file rispetto a una baseline, così le modifiche ai file di tema e plugin compaiono nel report → secaudit.eu

FAQ

DISALLOW_FILE_EDIT può compromettere il sito o gli aggiornamenti?

No. Rimuove soltanto i due editor della bacheca. Gli aggiornamenti di plugin, temi e core, compresi quelli automatici, continuano a funzionare. Solo DISALLOW_FILE_MODS cambia il modo in cui avvengono gli aggiornamenti.

Posso riattivare temporaneamente l'editor?

Sì. Impostate la costante su false oppure commentate la riga, poi ripristinatela. Meglio però modificare il file via SFTP o in staging, così l'editor non deve mai tornare.

WordPress ha questa impostazione nella bacheca?

No. Il core non prevede alcuna opzione in bacheca: è una costante da impostare in wp-config.php. Se non potete modificare quel file, usate un plugin che offra un interruttore per disattivare gli editor di file.