Durcissement WordPress : limiter l’installation de plugins et thèmes

Sur beaucoup de sites WordPress, la première faille ne vient pas d’un exploit exotique. Elle vient d’un geste simple: un utilisateur installe un plugin “utile”, un thème “pour tester”, puis oublie la mise à jour, ou donne des droits trop larges. Même sans intention malveillante, cette chaîne finit par fragiliser l’ensemble.

Limiter l’installation de plugins et de thèmes fait donc partie des mesures de durcissement WordPress les plus rentables. Le but n’est pas d’empêcher toute évolution, c’est de rendre l’évolution contrôlée, traçable et difficile à faire “à la volée”.

Le vrai risque derrière “n’importe qui peut installer”

WordPress sépare bien les rôles, mais l’interface admin peut donner une impression de simplicité: on clique, on installe, on active. Or, l’installation n’est pas seulement un changement esthétique. C’est du code qui s’ajoute au site, avec des accès potentiels aux données, aux actions planifiées, aux webhooks, aux options et parfois aux formulaires d’authentification.

Sur un site géré par plusieurs personnes, j’ai vu des scénarios très banals:

un nouveau membre de l’équipe obtient le rôle “Auteur” ou “Editeur” “pour gagner du temps”, puis installe un plugin pour un besoin immédiat; un prestataire termine un chantier, laisse un plugin pour “plus tard”, puis ne revient jamais pour les mises à jour; un plugin de sécurité ou de cache devient la nouvelle bête noire, car il modifie des règles serveur ou des headers mal comprises.

Dans ces cas, ce n’est pas l’installation en soi qui est dangereuse, c’est l’absence de contrôle, la non-maîtrise du cycle de vie (audit, conformité, mises à jour), et la difficulté à savoir qui a changé quoi.

Comprendre où se joue le contrôle dans WordPress

WordPress propose plusieurs couches de contrôle, et elles ne se recouvrent pas parfaitement.

D’abord, il y a la logique de rôles et de capacités. Ensuite, il y a les constantes de configuration qui bloquent les actions liées aux fichiers, à l’édition et parfois à l’installation. Enfin, il y a la structure du site, notamment la différence entre un WordPress “simple” et un WordPress en multisite.

Le durcissement efficace consiste à combiner ces couches, pas à compter sur une seule.

Vérifier vos rôles, car le paramètre seul ne suffit pas

Avant de verrouiller quoi que ce soit, commencez par un inventaire des comptes et des rôles. Un site durci uniquement “par paramètre” peut quand même https://gardewp.fr/securite-wordpress/ rester exposé si, par exemple, un compte admin a été prêté à quelqu’un “le temps de”.

L’approche que j’utilise en audit est simple: je liste qui a les droits d’administration, puis j’identifie la raison de ces droits. Un administrateur doit vraiment être un rôle rare.

Quand je vois des comptes admin distribués à l’équipe, je préfère une logique “fractionnée”:

un ou deux comptes admin pour les changements structurels, des comptes éditoriaux pour produire et maintenir le contenu, éventuellement des comptes spécifiques pour la maintenance, mais sans droits d’installation.

Bloquer l’installation et l’édition côté serveur via wp-config.php

La façon la plus robuste de limiter l’installation de plugins et de thèmes consiste à bloquer la modification de fichiers depuis l’interface WordPress. Même si quelqu’un possède un rôle élevé, WordPress ne devrait plus pouvoir écrire ou installer des éléments en utilisant son mécanisme natif.

Dans wp-config.php, on s’appuie généralement sur des constantes qui contrôlent l’accès aux opérations liées au système de fichiers. Les plus utiles dans ce contexte sont:

DISALLOW_FILE_MODS DISALLOW_FILE_EDIT

L’idée est la suivante: empêcher l’édition de fichiers et la modification via l’interface admin, ce qui réduit fortement la surface d’attaque.

Exemple de paramétrage (à adapter à votre contexte exact):

Define('DISALLOW_FILE_MODS', true); Define('DISALLOW_FILE_EDIT', true);

Effets pratiques attendus:

l’onglet permettant d’installer et de modifier via l’admin devient inutilisable selon les cas; l’édition de fichiers (éditeur de thème, édition de plugin) est bloquée; certaines fonctionnalités d’installation peuvent rester disponibles si le serveur autorise des flux particuliers, mais en général vous réduisez beaucoup le risque d’action “dans le navigateur”.

Point de vigilance: selon votre configuration d’hébergement et votre version de WordPress, certains écrans peuvent changer de comportement. L’approche “bloquante” est bonne, mais il faut tester en conditions réelles avec un compte ayant un rôle élevé (et idéalement un compte admin et un compte “moins fort”).

Le cas particulier du multisite: installer n’importe où, c’est installer partout

Si vous utilisez WordPress en multisite, la logique change un peu. Un super admin peut avoir une autorité globale, et les sites peuvent avoir leurs propres règles.

Dans un multisite, je traite l’installation de plugins et de thèmes comme un sujet plus sensible encore, car le dommage potentiel peut se propager. Bloquer l’installation “au niveau global” est souvent préférable à un verrouillage uniquement “local”.

Le levier exact dépend de votre configuration (réseau, paramètres, rôles). Mais le principe de durcissement reste identique: limiter les personnes capables de déclencher une modification de code, surtout depuis l’interface.

Retirer le bouton, ou empêcher l’action: deux niveaux à distinguer

Beaucoup de gens pensent en termes d’interface: masquer le bouton “Ajouter un plugin”. C’est utile, mais c’est surtout un confort.

La vraie barrière est fonctionnelle, pas visuelle. Un attaquant qui a une session ou une capacité ne doit pas pouvoir contourner le clic. Dans WordPress, le contournement peut exister si:

les capacités ne sont pas bien restreintes, l’installation reste possible par un autre endpoint, des plugins permettent d’installer autre chose, ou d’exécuter des actions indirectes.

Donc, même si vous administrez “proprement”, verrouiller les actions côté serveur et contrôler les capacités reste la base.

Concrètement, comment limiter l’installation selon les objectifs

Vous n’avez pas tous le même besoin. Un site vitrine isolé n’a pas les mêmes contraintes qu’une plateforme multi-équipes ou un site à forte fréquence de changements.

Voici la grille de décision que j’utilise, sans rigidité, mais avec un bon niveau de pragmatisme.

Cas fréquents et ce que vous cherchez à obtenir

Si votre objectif est simplement d’empêcher les rôles non-administrateurs d’installer quoi que ce soit, la combinaison rôles + constantes de blocage est généralement suffisante.

Si votre objectif est d’empêcher même l’administrateur d’installer depuis l’interface (pour forcer un processus de déploiement contrôlé), alors DISALLOW_FILE_MODS et DISALLOW_FILE_EDIT prennent toute leur valeur.

Si votre objectif est de garder la possibilité d’installer, mais uniquement sur un ensemble limité de thèmes, ou via un workflow approuvé, alors vous devez ajouter une couche applicative et organisationnelle, par exemple:

installation par CI/CD ou par déploiement “sur serveur”, validation en revue avant déploiement, contrôles d’intégrité et inventaire des versions installées.

Le point clé: une politique “tout bloquer” marche, mais elle peut ralentir. Une politique “semi-ouverte” marche aussi, mais elle exige une discipline de validation.

Une approche organisationnelle qui évite les contournements

Le durcissement n’est pas qu’un paramètre technique. Si vous bloquez l’installation sans proposer une alternative, les équipes cherchent une voie de secours. Souvent, la voie de secours devient pire que le problème initial: quelqu’un installe sur un poste, puis transfère le ZIP “à la main”, ou demande un nouveau compte admin à chaque urgence.

Sur un projet où nous avions durci l’installation, le changement a échoué au départ. Les devs avaient besoin de tester des thèmes rapidement. On avait bloqué l’interface, puis on a constaté que les demandes passaient en urgence et qu’elles généraient des installations en dehors du cycle attendu.

La correction a été simple: on a défini un environnement de test et un canal d’installation validé (toujours le même), puis on a limité le nombre de personnes habilitées. Résultat: moins de bricolage, plus de prévisibilité.

Ce que vous devez tester après verrouillage (sinon vous cassez sans le savoir)

Après modification de wp-config.php ou des capacités, l’équipe a parfois des surprises, non pas de sécurité, mais de fonctionnement.

Par exemple:

l’éditeur de thème ne doit plus être accessible; les options qui déclenchent des flux d’installation doivent échouer proprement; certains outils d’administration peuvent s’appuyer sur des actions de mise à jour ou d’installation.

Je recommande de tester avec deux comptes:

un admin, un rôle “éditeur” ou “auteur” (celui que vous estimez non habilité).

Et surtout, testez la partie “installation” depuis l’interface, mais aussi les liens cachés par certaines pages admin. Des écrans peuvent rester visibles, même si l’action est bloquée.

Définir une politique de déploiement: la meilleure barrière est le processus

Si vous voulez réellement sécuriser, vous devez décider où et comment le code arrive sur le serveur.

En pratique, la plupart des équipes choisissent l’un de ces schémas:

déploiement via accès serveur (FTP/SFTP ou outil d’hébergement), déploiement via un pipeline (CI/CD), déploiement via un outil géré par l’hébergement.

Peu importe la méthode. Le principe est de limiter les actions “à la main depuis wp-admin” et de conserver un historique de déploiement.

Quand une entreprise me dit “on installe seulement des plugins recommandés”, je demande toujours: “qui valide, qui déploie, et où est tracée la décision?”. La réponse détermine si le durcissement tiendra dans la durée.

Paramétrer proprement les mises à jour, sinon le verrouillage crée un angle mort

Limiter l’installation de plugins et de thèmes peut vous donner un faux sentiment de sécurité si vous négligez les mises à jour. Or, la surface d’attaque évolue avec le temps.

Un verrouillage trop strict peut inciter les utilisateurs à:

ignorer les notifications de mise à jour, repousser les mises à jour “parce qu’on ne peut pas installer facilement”, contourner la règle via des méthodes indirectes.

La bonne pratique consiste à définir un rythme de maintenance. Sur un site à trafic standard, on peut viser une mise à jour régulière, avec un cycle de test. Le point exact dépend de votre contrainte de service, mais la logique doit être claire: bloquer l’installation depuis l’interface ne doit pas bloquer la maintenance.

Deux actions rapides à mettre en place dès aujourd’hui

Si vous souhaitez un point de départ concret, voici deux actions très simples, que j’ai vues fonctionner dans des environnements différents.

1) Verrouiller les modifications de fichiers dans wp-config.php

Vérifiez que DISALLOW_FILE_MODS et DISALLOW_FILE_EDIT sont en cohérence avec votre besoin. Ensuite testez en admin et avec un rôle non habilité. L’objectif est d’éviter que quelqu’un puisse installer ou éditer depuis l’interface.

2) Réduire les comptes ayant des droits d’administration

Faites un nettoyage: retirez les droits d’admin aux comptes qui n’ont pas besoin de déployer du code. Pour les tâches éditoriales, utilisez des rôles adaptés.

Gestion fine: autoriser quelques actions, mais pas l’installation

Il y a une nuance importante: limiter l’installation ne veut pas forcément dire empêcher tous les changements.

Vous pouvez autoriser des actions comme:

la création et publication de contenu, la gestion de médias si nécessaire, des réglages non liés au code.

Le piège, c’est de surajouter des exceptions dans l’espoir d’être “flexible” tout en restant sécurisé. Chaque exception est un point d’entrée potentiel, surtout si les droits sont distribués.

Dans les projets où je dois rester pragmatique, je privilégie des exceptions minimales et documentées: “ce rôle fait cela, et uniquement cela”. Et je limite le nombre de rôles différents qui existent réellement.

Empêcher les thèmes et plugins non validés, sans casser la production

Limiter l’installation ne veut pas dire forcément bloquer toutes les nouveautés. Une autre approche consiste à s’appuyer sur un catalogue interne validé. Dans cette logique, ce n’est pas l’interface WordPress qui est le décideur, c’est votre processus.

Concrètement, l’équipe:

choisit un plugin ou un thème validé, déploie via un canal maîtrisé, surveille après déploiement.

Le bénéfice est double: vous réduisez le risque technique, et vous réduisez aussi le risque humain, parce qu’il y a moins de décisions prises “dans l’urgence”.

Le piège des plugins “gestionnaires” et des scripts externes

Même si vous verrouillez WordPress, certains plugins ou services externes peuvent réintroduire une capacité d’installation ou d’exécution de code.

Je pense notamment aux outils d’automatisation, aux connecteurs de marketplace interne, ou aux plugins “multi-sites” qui gèrent une partie du cycle de vie. Leur rôle peut sembler légitime, mais ils finissent parfois par donner à des comptes non prévus des moyens d’action.

La question à se poser est simple: “cet outil a-t-il besoin de modifier des fichiers, d’installer, ou d’exécuter des opérations sensibles?”. Si la réponse est oui, alors le verrouillage doit s’étendre à l’ensemble de la chaîne, pas uniquement à l’interface WordPress.

Contrôle régulier: vérifier ce qui est installé et ce qui a changé

Le durcissement n’est pas un état permanent. C’est un système. Si vous bloquez l’installation, vous devez aussi surveiller ce qui se passe ailleurs: migrations, mises à jour automatiques, déploiements opérés depuis le serveur, ou changements via un processus externe.

Sans donner de recette universelle, je recommande au minimum une routine d’inventaire:

vérifier périodiquement la liste des plugins et thèmes, contrôler leurs versions, repérer rapidement toute anomalie.

Sur un site que nous gérions, une différence minuscule de version de plugin a suffi à déclencher un dysfonctionnement d’affichage, sans être une faille au sens strict. C’est typiquement le genre de problème que le “contrôle régulier” évite, tout en renforçant la sécurité.

Un exemple de politique de droits qui marche bien

Pour rendre le tout applicable, voici un modèle de politique que j’ai vu fonctionner dans plusieurs contextes, avec bien sûr des adaptations selon la taille de l’équipe.

Deux comptes admin max pour le déploiement et la maintenance. Les rôles éditoriaux pour la production de contenu, sans droit d’installation. Installation et déploiement faits via le serveur ou un pipeline. Une procédure de validation avant toute nouveauté (plugin ou thème). Une cadence de mise à jour planifiée, même si l’installation depuis l’interface est bloquée.

Cette politique ne repose pas sur l’interface. Elle repose sur des responsabilités claires.

Faire la part des choses entre sécurité et productivité

Limiter l’installation est souvent un excellent compromis, parce que la plupart des sites n’ont pas besoin que des utilisateurs installent des plugins au quotidien. Le coût vient surtout quand votre équipe travaille en mode “test fréquent” ou quand le site vit en expérimentation.

Dans ces cas, vous pouvez conserver une certaine souplesse en séparant les environnements:

un environnement de test où l’on déploie pour valider, un environnement de production strictement contrôlé.

Le durcissement en production devient alors un verrou utile, pas une contrainte permanente.

Checklist de durcissement orientée plugins et thèmes

Voici une petite checklist, orientée action, pour vérifier que le verrouillage est réel et pas uniquement théorique.

Vérifiez la présence et la cohérence de DISALLOW_FILE_MODS et DISALLOW_FILE_EDIT dans wp-config.php. Testez l’installation et l’édition avec un compte admin et un compte non admin. Réduisez le nombre de comptes ayant des droits d’administration. En multisite, assurez-vous que la restriction couvre la bonne échelle (réseau et sites). Mettez en place un processus de déploiement maîtrisé, avec une trace des changements.

Ce que vous gagnerez, concrètement

Quand la limitation d’installation est bien faite, vous obtenez plusieurs effets cumulés:

moins de code introduit sans validation, moins de plugins orphelins, moins de “dépannages” en urgence qui finissent par rester, une meilleure maîtrise des mises à jour, une surface d’attaque réduite dans le navigateur, mais aussi dans les mécanismes associés.

Et le plus important, c’est que vous transformez un risque diffus en un processus. WordPress reste flexible, mais votre site ne l’est plus “n’importe comment”.

Dernier point de bon sens: documenter la règle

Il y a un détail que j’ignore rarement: documenter la règle interne, pas seulement dans un fichier technique. Une phrase suffit, mais elle doit être visible et partagée, par exemple dans un wiki d’équipe.

Quand une règle est écrite, les demandes changent de nature. Au lieu de “quelqu’un peut installer un plugin ?”, vous passez à “voici le plugin demandé, voici pourquoi, voici la validation, voici la date de déploiement”. C’est exactement ce que le durcissement cherche à provoquer.

Si vous voulez un durcissement durable, celui-ci doit s’entendre comme une règle de fonctionnement. C’est souvent plus efficace que n’importe quel verrou supplémentaire.