Pourquoi désactiver l’éditeur de fichiers de thèmes et extensions WordPress

Dans le menu Apparence > Éditeur de WordPress se cache un outil que très peu d’administrateurs utilisent volontairement, et que pourtant presque personne ne désactive. Il permet de modifier directement, depuis le navigateur, le code PHP des fichiers du thème actif. Un équivalent existe pour les extensions dans Extensions > Éditeur.

Sur le papier, c’est pratique pour corriger une ligne de CSS rapidement sans passer par FTP. Dans les faits, c’est l’une des fonctionnalités les plus dangereuses de WordPress dès qu’un compte administrateur tombe entre de mauvaises mains. Voyons pourquoi, et comment la neutraliser proprement.

Ce que permet réellement cet éditeur

L’éditeur de thèmes et d’extensions donne un accès en écriture direct aux fichiers PHP exécutés par le serveur. Concrètement, quiconque a les droits pour l’utiliser peut :

• Insérer n’importe quel code PHP dans functions.php ou tout autre fichier du thème actif ;
• Modifier le code d’une extension activée, y compris des fonctions appelées à chaque chargement de page ;
• Exécuter, de fait, n’importe quelle commande système que PHP autorise sur ce serveur, sans jamais toucher à FTP ni SSH.

Autrement dit, cet éditeur transforme un accès à l’administration WordPress en équivalent d’un accès shell limité au périmètre PHP. C’est une fonctionnalité conçue pour un contexte de confiance totale entre tous les comptes administrateurs, un contexte qui ne correspond à la réalité d’aucun site en production.

Le scénario qui justifie de le désactiver

Le risque ne vient pas d’une faille technique dans l’éditeur lui-même, mais de ce qu’il permet une fois qu’un compte administrateur est compromis, que ce soit par un mot de passe faible, un phishing réussi ou une session volée. Sans l’éditeur, un attaquant qui obtient un accès administrateur doit encore trouver un autre moyen d’exécuter du code sur le serveur. Avec l’éditeur actif, ce moyen est déjà fourni, en deux clics, dans l’interface elle-même.

C’est un principe de défense en profondeur : même si une couche de sécurité cède (le mot de passe admin), il ne faut pas que la couche suivante s’effondre automatiquement avec elle.

Désactiver l’éditeur avec DISALLOW_FILE_EDIT

La constante DISALLOW_FILE_EDIT, ajoutée dans wp-config.php, retire purement et simplement les menus Éditeur de thèmes et Éditeur d’extensions de l’administration :

define( 'DISALLOW_FILE_EDIT', true );

Cette ligne suffit à faire disparaître les deux écrans, quel que soit le rôle de l’utilisateur connecté, y compris un super-administrateur sur un réseau multisite. Aucun effet de bord n’est à craindre : cette fonctionnalité n’est jamais utilisée par le cœur de WordPress ni par une extension légitime pour fonctionner.

Aller plus loin avec DISALLOW_FILE_MODS

Une seconde constante, plus radicale, bloque en plus l’installation, la mise à jour et la suppression de thèmes et d’extensions depuis l’administration :

define( 'DISALLOW_FILE_MODS', true );

Attention : cette constante inclut automatiquement DISALLOW_FILE_EDIT, elle est donc redondante avec elle, mais surtout, elle empêche aussi les mises à jour automatiques et manuelles depuis l’interface. Elle convient à des contextes bien précis, où toutes les modifications de code passent obligatoirement par un déploiement contrôlé (Git, intégration continue) et jamais par l’interface WordPress. Sur un site classique géré au jour le jour depuis l’administration, je recommande plutôt de se limiter à DISALLOW_FILE_EDIT, pour garder la possibilité de mettre à jour les extensions en un clic.

Ce que ça ne remplace pas

Désactiver l’éditeur de fichiers réduit une surface d’attaque, mais ce n’est pas une protection contre tout :

• Un attaquant qui a un accès FTP, SSH ou au gestionnaire de fichiers de l’hébergeur peut toujours modifier les fichiers directement ;
• Une extension malveillante installée volontairement contourne cette protection puisqu’elle exécute déjà du code au moment de son activation ;
• Cela ne dispense en rien de mots de passe robustes et, quand c’est possible, d’une authentification à deux facteurs sur les comptes administrateurs.

Je désactive systématiquement l’éditeur de fichiers sur chaque site que je livre, même pour un client unique avec un seul compte admin. Ce n’est pas une question de confiance envers le client, mais de réduire ce qu’un simple vol de session permet de faire.

En résumé

Ajouter define( 'DISALLOW_FILE_EDIT', true ); à wp-config.php prend dix secondes et retire une fonctionnalité que presque personne n’utilise volontairement, mais qu’un attaquant adorerait trouver active. C’est l’un des réglages à plus fort rapport bénéfice/effort de tout le durcissement WordPress, à appliquer dès la mise en ligne de n’importe quel site.