DISALLOW_FILE_EDIT : désactiver l'éditeur de fichiers WordPress

Ajoutez une ligne à wp-config.php : define( 'DISALLOW_FILE_EDIT', true );. Elle retire de l'administration l'éditeur de fichiers des thèmes et celui des extensions. Cela prend deux minutes et n'a aucun effet sur les mises à jour. Vous supprimez aussi le chemin le plus court entre un mot de passe administrateur volé et du code qui s'exécute sur votre serveur.

Cet article explique pourquoi DISALLOW_FILE_EDIT compte, comment le configurer sans risque et ce qu'il n'empêche pas. Il indique aussi dans quels cas la constante plus stricte DISALLOW_FILE_MODS justifie l'effort supplémentaire.

Pourquoi activer DISALLOW_FILE_EDIT : de la connexion admin au code exécuté

WordPress intègre deux éditeurs de code. L'éditeur de fichiers des thèmes se trouve sous Apparence pour les thèmes classiques, ou sous Outils pour les thèmes à blocs. L'éditeur de fichiers des extensions se trouve sous Extensions pour les thèmes classiques, ou lui aussi sous Outils pour les thèmes à blocs. Tous deux permettent aux administrateurs (aux super administrateurs en multisite) de modifier des fichiers PHP dans le navigateur et de les enregistrer, et le serveur exécute ce code au prochain chargement de page.

Une connexion administrateur équivaut donc, en pratique, à un accès shell. Une personne qui dispose d'un mot de passe admin obtenu par hameçonnage, réutilisé ou trouvé par force brute peut ouvrir functions.php et y coller une porte dérobée. Elle peut aussi ajouter une redirection cachée pour les visiteurs venus des moteurs de recherche, ou glisser un skimmer de cartes bancaires dans un modèle de paiement. Il ne lui faut ni FTP ni accès à l'hébergement, seulement l'identifiant et le mot de passe.

La plupart des sites en production n'ont jamais besoin d'éditer du code dans le navigateur. Les développeurs travaillent dans un éditeur de code, sur un environnement de préproduction ou via le gestionnaire de versions. Modifier du PHP en ligne dans un champ de texte, c'est travailler sans annulation possible et sans relecture, et une seule erreur de syntaxe peut mettre le site hors service. Sur un site d'entreprise en production, l'éditeur ajoute du risque et presque rien d'autre.

La protection de la connexion elle-même est un autre chantier, traité dans notre guide sur l'authentification à deux facteurs pour les administrateurs WordPress. DISALLOW_FILE_EDIT limite ce qu'un accès volé permet de faire.

Ajouter DISALLOW_FILE_EDIT à wp-config.php

1. Téléchargez une copie de wp-config.php et gardez-la comme sauvegarde. Chez beaucoup d'hébergeurs, le fichier est à la racine de WordPress. Certaines installations le placent un répertoire au-dessus.
2. Ouvrez le fichier en SFTP ou avec le gestionnaire de fichiers de votre hébergeur. N'utilisez pas d'extension WordPress pour cela.
3. Cherchez DISALLOW_FILE_EDIT dans le fichier. Si la constante est déjà définie, modifiez cette ligne au lieu d'en ajouter une seconde. Définir deux fois une constante provoque un avertissement PHP.
4. Ajoutez la ligne au-dessus du commentaire qui commence par /* That's all, stop editing!. Elle doit précéder le chargement de wp-settings.php.
5. Enregistrez, envoyez le fichier sur le serveur et rechargez l'administration.

/* Désactiver les éditeurs de fichiers des thèmes et des extensions dans l'administration */
define( 'DISALLOW_FILE_EDIT', true );

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

Vérifiez ensuite le résultat. Les entrées de menu Éditeur de fichiers des thèmes et Éditeur de fichiers des extensions doivent avoir disparu. Si vous ouvrez directement /wp-admin/theme-editor.php, vous devez obtenir une erreur de droits au lieu de l'éditeur.

Impossible de réactiver cette constante depuis l'administration, et c'est voulu. Pour récupérer l'éditeur, il faut un accès aux fichiers du serveur, pas seulement un mot de passe admin. Le réglage s'applique à toute l'installation, et en multisite à chaque site du réseau. La documentation officielle de wp-config.php la répertorie avec les autres constantes de configuration.

Si vous n'avez ni accès SFTP ni gestionnaire de fichiers, l'extension Security Audit & Compliance de secaudit.eu propose une option qui désactive les éditeurs de fichiers de l'administration.

Ce que la désactivation de l'éditeur de fichiers n'empêche pas

DISALLOW_FILE_EDIT supprime la voie la plus facile. Il ne rend pas un compte administrateur inoffensif. Un administrateur, ou un attaquant qui se sert de son compte, peut toujours :

• téléverser un zip d'extension ou de thème contenant du code malveillant, via Extensions → Ajouter ou Apparence → Thèmes
• créer de nouveaux comptes administrateurs, changer l'adresse e-mail de l'admin ou réinitialiser le mot de passe d'autres utilisateurs
• modifier des réglages comme l'adresse du site, l'inscription des utilisateurs ou le rôle par défaut
• exporter les données des utilisateurs et des commandes

Un attaquant qui dispose d'un accès FTP, SSH, au panneau d'hébergement ou à la base de données contourne complètement WordPress, et aucune constante de wp-config.php ne l'arrête. La constante ne sert pas non plus contre les extensions vulnérables exploitables sans aucune connexion. C'est un problème distinct, avec ses propres remèdes, traité dans notre guide sur les extensions WordPress vulnérables.

Voyez DISALLOW_FILE_EDIT comme une couche parmi d'autres. Elle ne coûte presque rien et vaut largement d'être en place, mais elle ne corrige ni une authentification faible ni une extension non mise à jour.

Gestionnaires de fichiers et extensions d'extraits de code : l'éditeur sous un autre nom

Plusieurs types d'extensions rétablissent le même risque, et DISALLOW_FILE_EDIT ne les couvre pas :

• les extensions de gestion de fichiers, qui permettent de parcourir, modifier et téléverser des fichiers depuis l'administration
• les gestionnaires d'extraits de code, qui stockent du PHP et l'exécutent à chaque requête
• les champs « code d'en-tête/de pied de page », qui acceptent des scripts ou du PHP
• les options de thème ou de constructeur de pages dotées d'une zone « code personnalisé »

Si l'une d'elles est active, un attaquant qui possède un accès admin dispose toujours d'un éditeur de code.

Commencez par dresser l'inventaire. Parcourez Extensions → Extensions installées et les options de votre thème, et notez tout ce qui permet de modifier des fichiers ou d'exécuter du code personnalisé. Traitez ensuite chaque cas :

• Gestionnaires de fichiers : supprimez-les dès que la tâche ponctuelle est terminée. La désactivation ne suffit pas : le code reste sur le serveur et peut lui-même contenir des failles.
• Extraits dont vous avez vraiment besoin : déplacez-les dans une petite extension sur mesure ou dans un thème enfant, et gardez-les sous gestionnaire de versions. Les modifications passent alors par votre déploiement habituel, plus par le navigateur.
• Gestionnaires d'extraits que vous conservez : vérifiez quels rôles peuvent créer ou modifier des extraits, et limitez ce droit au plus petit nombre de personnes possible.

DISALLOW_FILE_MODS : un verrou plus fort, des contreparties réelles

define( 'DISALLOW_FILE_MODS', true ); va plus loin. Il bloque l'installation, la mise à jour et la suppression des extensions et des thèmes depuis l'administration. Il désactive aussi les mises à jour automatiques en arrière-plan de WordPress. Cela ferme la voie du téléversement de zip que DISALLOW_FILE_EDIT laisse ouverte.

Le prix à payer : plus rien ne se met à jour tout seul. Si personne n'applique les mises à jour autrement, le site prend peu à peu du retard sur les correctifs de sécurité. Les notifications de mise à jour habituelles disparaissent aussi de l'administration. Seul Santé du site signale que les mises à jour en arrière-plan sont désactivées, et cet écart passe facilement inaperçu.

Prévoir un circuit de mise à jour avant d'activer DISALLOW_FILE_MODS

Choisissez l'une de ces approches et faites-en une routine :

• WP-CLI sur le serveur. Lancez les mises à jour en ligne de commande, à la main ou par une tâche planifiée :

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

• Déploiement par Git ou Composer. Les versions des extensions et des thèmes sont définies dans votre dépôt, et un pipeline construit et déploie le site. Les mises à jour deviennent des commits que vous pouvez relire et annuler.
• Outils de mise à jour de l'hébergeur géré. Certains hébergeurs appliquent les mises à jour pour vous, souvent après une sauvegarde ou un contrôle visuel. Renseignez-vous précisément sur ce qui est couvert, et sur l'inclusion ou non des extensions premium.

Testez la méthode choisie sur une copie de préproduction où DISALLOW_FILE_MODS est déjà activé. La configuration de votre serveur détermine ce qui fonctionne, alors vérifiez-le avant de toucher à la production.

Planifiez les mises à jour avec une tâche cron ou un déclencheur de pipeline, et vérifiez que la tâche s'exécute réellement. Une tâche qui échoue en silence ne vaut pas mieux que pas de tâche du tout. Gardez une trace de ce qui a été mis à jour et quand. Ce journal constitue une preuve utile de « mesures techniques et organisationnelles appropriées » au sens de l'article 32 du RGPD.

La vitesse compte. Patchstack, éditeur de solutions de sécurité, indique dans son rapport State of WordPress Security in 2026 que le délai médian pondéré avant exploitation de masse était de 5 heures pour les vulnérabilités les plus exploitées. Une tournée de mises à jour manuelle une fois par mois ne suit pas ce rythme.

Vérifier que le verrou est toujours en place

Les constantes se perdent facilement lors des migrations, des changements d'hébergeur et des opérations de débogage « provisoires ». Contrôlez-les de temps en temps :

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

La première commande affiche chaque ligne correspondante avec son numéro. La seconde affiche la valeur que WP-CLI lit dans la configuration. Relancez les deux après chaque passage vers un nouveau serveur ou un nouvel hébergeur. Surveillez aussi les modifications inattendues des fichiers PHP de votre thème et de vos extensions. Quand le verrou est en place, un tel changement signifie que quelqu'un est entré par un autre chemin.

Si vous constatez que l'éditeur a déjà été utilisé contre vous, il ne s'agit plus de durcissement mais de réponse à incident. Lisez nos guides sur la détection des web shells et le nettoyage d'un WordPress infecté avant de toucher à autre chose.

L'extension d'audit de secaudit.eu vérifie vos réglages de durcissement et de configuration, y compris l'éditeur de fichiers. Elle suit aussi l'intégrité des fichiers par rapport à une référence : les modifications des fichiers de thèmes et d'extensions apparaissent dans le rapport → secaudit.eu

FAQ

DISALLOW_FILE_EDIT peut-il casser mon site ou les mises à jour ?

Non. Il retire seulement les deux éditeurs de l'administration. Les mises à jour des extensions, des thèmes et du cœur, y compris les mises à jour automatiques, continuent de fonctionner. Seul DISALLOW_FILE_MODS change le fonctionnement des mises à jour.

Puis-je réactiver l'éditeur temporairement ?

Oui. Passez la constante à false ou commentez la ligne, puis rétablissez-la ensuite. Mieux vaut cependant modifier le fichier en SFTP ou sur la préproduction, afin que l'éditeur n'ait jamais à revenir.

WordPress propose-t-il ce réglage dans l'administration ?

Non. Le cœur de WordPress n'offre aucune option dans l'administration : c'est une constante à définir dans wp-config.php. Si vous ne pouvez pas modifier ce fichier, utilisez une extension qui propose un interrupteur pour désactiver les éditeurs de fichiers.