Comment désactiver l'éditeur de thèmes et d'extensions avec DISALLOW_FILE_EDIT

Cachées dans toute installation WordPress par défaut se trouvent deux pages que presque personne n'utilise volontairement, mais qui transforment discrètement un mot de passe administrateur volé en compromission complète du serveur. Apparence, Éditeur de fichiers de thème et Extensions, Éditeur de fichiers d'extension. Les deux permettent à un administrateur d'éditer des fichiers PHP bruts à l'intérieur de l'installation directement via le navigateur. Les deux sont toujours activés par défaut en 2026. Et les deux sont entièrement optionnels.

Ce guide explique pourquoi désactiver les éditeurs est l'une des modifications de durcissement à plus fort effet de levier que vous puissiez apporter à un site WordPress, à quoi ressemble la ligne unique de configuration, et à quoi s'attendre par la suite (y compris quelques cas particuliers qui surprennent les gens).

Pourquoi l'éditeur de code intégré est-il un problème ?

Au quotidien, personne n'utilise l'éditeur. Les modifications de thème passent par un thème enfant ou par le pipeline de déploiement d'un développeur. Les modifications d'extensions se font sur la préproduction, pas en production. L'éditeur reste là, inutilisé, accessible uniquement aux administrateurs.

« Accessible uniquement aux administrateurs » est la partie qui se brise sous l'attaque. La façon dont la prise de contrôle WordPress typique se déroule n'a rien à voir avec des vulnérabilités au niveau du code dans l'éditeur lui-même. Cela ressemble à ceci :

1. Un mot de passe administrateur fuit. Phishing, réutilisation de mot de passe depuis un service compromis, un ordinateur portable de développeur infecté par un malware, une extension compromise qui exfiltre les cookies de session. Choisissez l'un des points d'entrée habituels.
2. L'attaquant se connecte à /wp-admin en tant qu'utilisateur administrateur réel. Du point de vue de WordPress, rien ne va mal, c'est une connexion légitime.
3. L'attaquant va directement à Apparence, Éditeur de fichiers de thème, ouvre functions.php et colle une petite porte dérobée PHP en haut.
4. À partir de ce moment, chaque requête sur la page d'accueil du site exécute le code de l'attaquant. Il a un shell distant sur votre serveur.

L'éditeur transforme « mot de passe administrateur volé » en « serveur web volé ». Sans lui, un attaquant qui vole un mot de passe administrateur dispose toujours d'un accès administrateur (ce qui est déjà assez grave), mais il doit emprunter le chemin plus lent et plus bruyant consistant à téléverser un zip d'extension ou de thème malveillant pour obtenir l'exécution de code. Cette étape supplémentaire est une chance de plus qu'une extension de sécurité, un scanner d'intégrité de fichiers ou un WAF au niveau serveur remarque et bloque le téléversement.

Le rapport coût/bénéfice est extrêmement déséquilibré. L'éditeur est utilisé quelques fois par an par une infime minorité d'administrateurs. Le risque apparaît sur chaque site qui subit une fuite d'identifiants. Désactiver l'éditeur est l'une de ces modifications où le pire des cas est « quelqu'un doit utiliser SFTP pour une modification de cinq minutes » et le meilleur des cas est « la prise de contrôle ne dégénère jamais d'une fuite de mot de passe à une porte dérobée ».

La solution : une seule ligne dans wp-config.php

WordPress dispose d'une constante intégrée pour exactement ce cas. Ouvrez wp-config.php dans le répertoire racine de WordPress et ajoutez la ligne suivante, n'importe où au-dessus du commentaire qui dit /* That's all, stop editing! Happy publishing. */ :

define('DISALLOW_FILE_EDIT', true);

Enregistrez le fichier. C'est tout. Le menu Éditeur de fichiers de thème sous Apparence et l'Éditeur de fichiers d'extension sous Extensions disparaissent immédiatement pour tous les utilisateurs, y compris les administrateurs. Les pages elles-mêmes renvoient une erreur de permission si elles sont accédées directement par URL. Pas d'extension à installer, pas de paramètre à maintenir, pas de surface de compatibilité à craindre. La constante fait partie du cœur de WordPress depuis la version 3.0 (publiée en 2010) et n'est pas près de disparaître.

Et si je veux aussi bloquer les téléversements d'extensions et de thèmes depuis l'admin ?

WordPress a une constante sœur plus stricte appelée DISALLOW_FILE_MODS. Elle fait ce que fait DISALLOW_FILE_EDIT, plus elle bloque les téléversements d'extensions, les téléversements de thèmes et les mises à jour du cœur depuis l'interface d'administration. Sa définition est identique :

define('DISALLOW_FILE_MODS', true);

Celle-ci entraîne un changement de comportement bien plus important. Avec DISALLOW_FILE_MODS actif, vous ne pouvez plus installer ni mettre à jour des extensions, des thèmes ou le cœur de WordPress via l'interface d'administration normale. Toutes les mises à jour doivent venir d'ailleurs : WP CLI, un pipeline de déploiement, un téléversement SFTP, ou le tableau de bord central d'un hébergeur managé.

Pour la plupart des sites, c'est trop restrictif. Les mises à jour sont la tâche de sécurité la plus importante sur un site WordPress, et les rendre plus difficiles signifie généralement que les gens les ignorent. DISALLOW_FILE_MODS a du sens dans deux environnements spécifiques : les pipelines de déploiement où l'installation de production est censée être en lecture seule, et les configurations à haute sécurité où quelqu'un est réellement responsable de pousser les mises à jour depuis l'extérieur. Pour tout le reste, le simple DISALLOW_FILE_EDIT trouve l'équilibre idéal entre « énorme gain de sécurité, aucune douleur opérationnelle ».

Qu'est-ce qui change pour les utilisateurs après l'avoir défini ?

Pour 99 % des administrateurs sur 99 % des sites : rien de visible. Les deux entrées de menu ont disparu du tableau de bord. Personne ne le remarque, parce que personne ne s'en servait.

Les cas où quelqu'un le remarque :

• Un développeur qui édite la production directement. Si quelqu'un dans l'équipe édite régulièrement les fichiers de thème ou d'extension via le navigateur, il devra passer à SFTP ou à un pipeline de déploiement. C'est un changement de flux de travail, pas un blocage. C'est même un bon moment pour se demander pourquoi du code de production est édité en direct en premier lieu.
• Des extensions qui s'accrochent à l'éditeur. Une petite poignée d'extensions étendent l'éditeur intégré avec des fonctionnalités supplémentaires. Leur interface ne se chargera tout simplement plus quand l'éditeur aura disparu. L'extension elle-même continue généralement de fonctionner, seule l'intégration de l'éditeur se brise. Si vous dépendez de l'une d'entre elles, vous verrez le manque pendant les tests.
• Du code personnalisé qui utilise les capacités edit_themes ou edit_plugins. La constante retire ces capacités à tous les rôles, y compris à l'administrateur. Le code qui conditionne des fonctionnalités à ces capacités exactes se comportera comme si personne ne les avait. Rare, mais bon à savoir si vous maintenez une extension personnalisée qui effectue ce type de vérification de capacités.

Vérifier que c'est actif

1. Connectez-vous à WordPress en tant qu'administrateur.
2. Ouvrez le menu Apparence dans la barre latérale d'administration. L'entrée « Éditeur de fichiers de thème » devrait être absente.
3. Ouvrez le menu Extensions. L'entrée « Éditeur de fichiers d'extension » devrait être absente.
4. Pour une vérification supplémentaire, naviguez directement vers https://votredomaine.com/wp-admin/theme-editor.php. WordPress doit vous rediriger vers une page qui dit « Désolé, vous n'êtes pas autorisé à modifier les fichiers de thème ».
5. Lancez une nouvelle analyse InspectWP. La vérification « éditeur de fichiers activé » dans la section sécurité doit passer au vert.

Si les entrées de menu sont toujours là après avoir enregistré wp-config.php, les raisons les plus courantes sont : cache d'objet (videz-le), cache d'opcode comme OPcache (il peut prendre un moment pour récupérer le nouveau fichier, ou vous pouvez redémarrer PHP FPM), la modification a atterri dans un mauvais wp-config.php dans un répertoire parent, ou la constante a été définie plus loin dans le fichier par autre chose et votre ligne est écrasée. Ouvrez wp-config.php tout en haut et cherchez DISALLOW_FILE_EDIT ; vous devriez voir votre ligne et rien d'autre qui la redéfinisse ensuite.

Ce que cette solution fait et ne fait pas

Il vaut la peine d'être clair sur le type d'attaque que DISALLOW_FILE_EDIT arrête, et sur ce qu'il laisse intact. Il arrête le chemin spécifique où un attaquant utilise une connexion administrateur volée pour écrire du PHP dans des fichiers de thème ou d'extension via le navigateur. Il n'arrête pas :

• Un attaquant qui téléverse un zip d'extension ou de thème malveillant depuis l'admin (utilisez DISALLOW_FILE_MODS pour cela, avec les compromis décrits ci-dessus, ou restreignez les capacités pour les téléversements d'extensions).
• Un attaquant qui exploite une vulnérabilité au niveau du code dans une extension pour écrire des fichiers. Cela nécessite que l'extension elle-même soit corrigée.
• Un attaquant qui a un accès SFTP ou shell. À ce stade, la couche WordPress est entièrement contournée.

DISALLOW_FILE_EDIT est une couche défensive, pas une stratégie complète. Il s'associe naturellement à des mots de passe administrateur forts, à l'authentification à deux facteurs sur les comptes administrateur et à une extension de sécurité qui surveille les modifications de fichiers inattendues. La combinaison supprime le chemin de prise de contrôle le plus facile et rend les chemins plus difficiles assez bruyants pour être remarqués.

Une ligne dans wp-config.php, pas d'extension, pas de maintenance, pas de surface de compatibilité. Si vous ne faites rien d'autre sur un site WordPress ce mois-ci, faites ceci.