Sur WordPress, la sécurité ne se joue pas seulement dans les thèmes, les plugins ou les mises à jour. Elle se joue aussi dans les permissions. Le scénario est tristement banal : un compte « auteur » ou « éditeur » devient l’entrée la plus facile vers une modification non prévue. Un salarié qui change de poste, un prestataire qui conserve l’accès, un compte compromis qui sert de tremplin. Et souvent, la surprise vient du fait que le rôle censé être « cadré » a en réalité plus de pouvoir qu’on ne l’imagine.
Limiter l’accès aux éditeurs et aux auteurs, ce n’est pas juste cocher quelques cases dans WordPress. C’est une démarche de moindre privilège, à relier à votre organisation (qui fait quoi), à votre stack (rôles et plugins) et à votre manière de publier (workflow, validation, relectures).
Pourquoi le rôle “éditeur” mérite qu’on s’en occupe
Dans WordPress, les rôles sont conçus pour gérer l’écriture et la publication, pas pour être un verrou de sécurité à l’échelle d’un parc. Le rôle d’éditeur peut publier, modifier les contenus des autres, et accéder à l’interface d’administration. Selon vos réglages, un éditeur peut aussi toucher à des éléments sensibles via l’écran d’édition (médias, commentaires, tags, catégories, etc.). Un auteur, en général, a des droits plus restreints, mais il peut quand même créer un contenu qui déclenche des comportements que vous n’attendiez pas, par exemple via des shortcodes, des champs personnalisés, ou certains plugins d’optimisation SEO.
Le point clé, c’est que l’attaquant ne cherche pas toujours à « casser » WordPress. Il cherche souvent à modifier discrètement un contenu, injecter un lien, changer un redirection, ou publier une page qui ressemble à une page légitime. Dans ces cas-là, le plus dangereux n’est pas le poste de l’administrateur, c’est celui d’une personne “suffisamment proche” du contrôle pour que le changement passe sous le radar.
Je me souviens d’un site éditorial où l’équipe utilisait un plugin de champs avancés pour construire des pages. Les auteurs avaient le droit de modifier leurs brouillons, mais pas les pages publiées. Une fois, un compte auteur a été compromis via un mot de passe réutilisé. Le code malveillant n’a pas été injecté dans un fichier PHP, il a été ajouté dans un champ qui alimentait un bloc rendu sur le front. Le site n’a pas affiché d’erreur, il a juste commencé à renvoyer des ressources douteuses sur certaines pages. C’est typiquement le genre de problème que “limiter l’accès” doit anticiper, pas seulement “sécuriser l’accès administrateur”.
Comprendre ce que WordPress considère comme “pouvoir”
WordPress repose sur des capacités (capabilities) attachées aux rôles. Quand vous limitez l’accès, votre objectif n’est pas de changer le nom du rôle, mais de retirer des capacités précises. Par exemple, ce que vous considérez comme “juste écrire” se traduit par des autorisations concrètes : gérer les pages, modifier les publications des autres, importer des médias, gérer les catégories, etc.
Deux pièges reviennent souvent :
1) Confondre “rôle” et “ce que l’interface laisse faire”. Vous pouvez rendre un menu invisible, mais garder une capacité active. L’attaquant peut alors appeler une URL ou un endpoint directement, ou forcer une action via des requêtes forgées.
2) Penser que l’auteur est inoffensif parce qu’il ne voit que ses contenus. Si votre site utilise des fonctionnalités étendues, il peut avoir accès à des écrans ou des options qui ne sont pas dans votre logique éditoriale. Les champs personnalisés, les plugins de formulaires, les intégrations marketing, tout cela peut créer des surfaces supplémentaires.
La bonne approche consiste à vérifier, pour chaque niveau (éditeur, auteur), ce que vous acceptez réellement comme actions. Publier ? Éditer uniquement ses brouillons ? Modifier les médias ? Créer des catégories ? Gérer les commentaires ? Changer des paramètres liés au plugin SEO ? Sans répondre à ces questions, vous “limitez” sans savoir ce que vous protégez.
Établir un modèle de workflow avant de toucher aux rôles
Avant de modifier quoi que ce soit, il faut clarifier le workflow. Par exemple, un site peut fonctionner avec validation interne : l’auteur écrit, l’éditeur relit, puis une personne restreinte publie. Un autre site fonctionne en direct : l’éditeur publie et l’auteur écrit sans validation. Ce sont deux modèles différents, et ils ne devraient pas produire les mêmes permissions.
L’intérêt de cette étape, c’est qu’elle évite une correction à l’aveugle. J’ai déjà vu des équipes retirer trop de capacités à des auteurs, puis compenser en leur redonnant ensuite les droits “au cas où”, jusqu’à revenir à un état proche du départ. Une règle simple aide : partez des actions minimales nécessaires pour atteindre le workflow prévu, puis retirez le reste.
Dans un modèle classique de validation, vous pouvez viser un principe simple : l’éditeur valide et modifie, mais ne publie pas sans un dernier contrôle. Cela n’est pas une règle universelle, mais c’est souvent un excellent levier de sécurité, car un compromis d’un compte “éditeur” ne se transforme pas immédiatement en publication à grande portée.
Limiter l’accès aux auteurs : les leviers utiles
Pour un rôle auteur, le danger n’est pas seulement “publier”, c’est aussi “modifier la surface front” via des contenus et des dépendances. La première question pratique est donc : quelles contributions sont autorisées, et lesquelles doivent passer par l’éditeur ou l’admin ?
Réduire le pouvoir éditorial
Selon votre organisation, l’auteur n’a pas forcément besoin de gérer des taxonomies. S’il peut créer des catégories, il peut forcer des pages d’archives à être créées ou modifiées, ce qui peut devenir un angle d’injection si vous utilisez des gabarits spécifiques. De même, les médias sont un point d’attention : autoriser le téléchargement et la modification des fichiers augmente la probabilité d’exposer des contenus non souhaités.
Le compromis à gérer ici est simple : plus vous coupez, plus l’équipe éditoriale dépend d’une personne qui fera la mise en forme finale. C’est acceptable, mais il faut l’assumer. Une bonne sécurité est rarement invisible côté métier.
Cas concret : les shortcodes et les plugins
Un auteur peut utiliser des shortcodes. Si certains shortcodes permettent d’insérer des scripts, d’interroger des endpoints externes ou d’accéder à des paramètres sensibles, vous avez un risque direct, même sans fichier PHP. Je recommande de cartographier les shortcodes et blocs réellement utilisables par les auteurs dans votre environnement.
Si vous utilisez Gutenberg, la question ne se limite pas aux shortcodes. Certains blocs viennent de plugins, et certains plugins exposent des options plus ou moins “safe”. Là encore, ce n’est pas une question de méfiance automatique, c’est une question de permissions et d’intention : les auteurs doivent pouvoir créer du contenu, pas configurer des intégrations.
Limiter l’accès aux éditeurs : ce que vous voulez empêcher
Les éditeurs sont souvent les plus difficiles à cadrer parce qu’ils sont l’interface opérationnelle. Si vous retirez trop de capacités, vous bloquez la production. Si vous ne retirez rien, vous augmentez l’impact potentiel d’un compte compromis.
L’approche consiste à distinguer deux besoins :
- l’édition de contenus existants (réécriture, corrections, mise en forme) la gestion d’options globales et la modification de structure (où un changement peut toucher tout le site)
Typiquement, vous voulez que l’éditeur modifie des articles et pages, mais qu’il ne touche pas aux réglages structurants. Cela concerne les menus d’administration et, plus important encore, les actions derrière ces menus.
Savoir où un éditeur peut aller malgré tout
WordPress ne “verrouille” pas seulement des écrans, il exécute des actions conditionnées par des capacités. Si un plugin ou un thème expose une fonctionnalité via une URL accessible, ou si un écran permet d’initier une action sensible, un rôle trop large peut suffire à lancer une modification.
Un cas fréquent : la gestion des médias, puis l’insertion de contenus. Un autre : les commentaires et la modération, où un acteur malveillant peut laisser passer un lien ou perturber la réputation du site.
Et puis il y a les réglages plugin. Même si vous n’accordez pas explicitement l’accès aux réglages WordPress, certains plugins créent leurs propres pages d’administration, parfois sous un menu accessible à des rôles non prévus. Ce n’est pas toujours une faille, mais c’est une surface de contrôle qui doit être alignée avec votre politique.
Les techniques concrètes pour appliquer la moindre privilège
Dans la pratique, vous allez jouer sur trois niveaux : WordPress natif, configuration, et éventuellement personnalisation des rôles. L’objectif, c’est d’obtenir une séparation claire entre “écrire” et “administrer”.
1) Vérifier et corriger ce que permettent déjà vos rôles
Commencez par auditer vos rôles actuels. WordPress permet de gérer des capacités via des plugins ou par code, mais même sans modification, vous pouvez faire un audit fonctionnel : pour chaque action qu’un auteur ou éditeur doit faire, vérifiez que l’interface fonctionne correctement, et que l’interface n’offre pas d’actions que vous ne voulez pas.
Si vous avez des comptes qui n’ont qu’un rôle “éditeur” mais travaillent comme “administrateur”, c’est souvent là que ça dérape. La correction peut être simple : réduire le rôle au bon niveau, puis ajuster les capacités uniquement si nécessaire.
2) Ajuster l’accès aux pages, médias et taxonomies
Selon la nature du site, vous pouvez réduire ce qui va au-delà de la production éditoriale. Un auteur peut garder la capacité de créer et modifier ses brouillons, mais ne pas gérer globalement les médias. Un éditeur peut modifier des contenus, mais ne pas gérer certaines catégories, si cela dépend d’un administrateur.
Attention au piège du “trop restrictif”. Si votre CMS dépend fortement des taxonomies pour l’architecture, couper la gestion des catégories peut coûter du temps. Le bon compromis est souvent de centraliser la création des catégories, puis de laisser les éditeurs associer leurs contenus à des catégories existantes.
3) Créer des rôles sur mesure plutôt que “bricoler” en permanence
Un rôle “auteur validé” ou “éditeur relecteur” peut réduire la tentation de sur-déléguer. L’idée n’est pas de multiplier les rôles à l’infini, mais de créer des profils proches de votre workflow réel.
Avec un rôle sur mesure, vous pouvez retirer les capacités de publication directe, limiter la gestion des options, et restreindre l’accès aux écrans d’administration sensibles. Cela évite le jeu de ping-pong entre opérationnels et administrateurs.
4) S’assurer que les actions ne restent pas accessibles via des URL
Même si l’interface ne montre pas un menu, les actions peuvent parfois rester joignables par d’autres moyens si les capacités existent. C’est un point qui se vérifie mieux en test qu’en théorie.
Je conseille de prendre 30 minutes pour simuler un rôle auteur et un rôle éditeur, puis d’essayer d’ouvrir directement certaines pages d’administration que vous ne voulez pas qu’ils voient. L’objectif n’est pas de “trouver une faille”, c’est de confirmer que les droits sont réellement appliqués.
5) Penser REST API et endpoints AJAX
WordPress expose des endpoints, et certains plugins utilisent aussi des appels AJAX côté client. Si un éditeur a des droits larges, ces endpoints peuvent devenir exploitables pour obtenir ou modifier des informations.
Vous n’avez pas besoin de transformer WordPress en coffre-fort militaire. Il faut juste éviter que des capacités non nécessaires soient attribuées. Dans un contexte sécurité, un bon réflexe consiste à vérifier quels plugins ajoutent des actions côté backend, et quels rôles sont réellement autorisés à les déclencher.
Sécurité WordPress : limiter l’accès aux éditeurs et auteurs, mais sans casser la production
Un cadre efficace, c’est celui qui protège sans ralentir à l’excès. Un compte auteur doit pouvoir travailler. Un compte éditeur doit valider, corriger, harmoniser. Si vous mettez des barrières trop tôt, l’équipe contourne. Et là, vous perdez le bénéfice de la politique.
Un point pratique : quand vous limitez la publication directe, vous devez aussi régler le processus de validation. Sinon, vous créez un goulot d’étranglement qui pousse à rouvrir des droits pour “aller plus vite”. La sécurité n’évolue pas en dehors du fonctionnement, elle s’y intègre.
Voici une approche qui marche bien dans les équipes éditoriales :
- garder l’auteur sur la création et l’édition de son contenu, sans pouvoir modifier le site global garder l’éditeur sur la correction, la relecture et la mise en forme, avec des droits de publication contrôlés réserver les modifications de structure, réglages globaux et gestion des extensions à des profils restreints
Si votre équipe n’est pas prête pour ce modèle, vous pouvez commencer plus doucement, par exemple en retirant d’abord les droits les plus “impactants” (publication directe, gestion des options de plugins critiques), puis en durcissant ensuite.
Un plan d’action simple, testable et durable
Plutôt que de faire un grand “gros changement rôles” un vendredi soir, mieux vaut procéder par étapes, avec un contrôle.
Voici un plan pragmatique :
- lister les actions autorisées à chaque rôle (créer, modifier, publier, gérer médias, gérer taxonomies) tester chaque action depuis un compte éditeur et un compte auteur, en vérifiant qu’ils n’accèdent pas aux écrans ou actions non attendus réduire progressivement les capacités jugées inutiles, une catégorie à la fois, pour mesurer l’impact journaliser et surveiller les modifications de contenu et les actions sensibles pendant une période d’observation
Le point délicat est le “mesurer l’impact”. Si l’éditeur ou l’auteur ne peuvent plus faire leur travail, vous recevrez des demandes de rétablissement. D’où l’importance d’identifier avant les actions indispensables. On n’est pas en train de “mettre des freins”, on est en train de cadrer.
Les pièges courants quand on restreint les rôles
Il y a https://gardewp.fr/securite-wordpress/ des erreurs de sécurité qui ressemblent à des erreurs de configuration. Elles reviennent souvent :
Premièrement, confondre visibilité et autorisation. Retirer un menu, ce n’est pas retirer la capacité. Si vous ajustez des droits via un plugin ou un réglage, vérifiez que les actions associées sont bloquées aussi.
Deuxièmement, ignorer les dépendances des plugins. Un plugin peut ajouter des écrans, des shortcodes, des boutons ou des flux. Quand vous retirez une capacité, vous pouvez casser une fonctionnalité. La tentation est alors de redonner des droits “pour que ça marche”. C’est là que la sécurité se dégrade en spirale.
Troisièmement, ne pas revoir les droits après les changements d’équipe. Un auteur qui devient éditeur, un prestataire qui quitte, un compte qui reste en place. La sécurité par rôles tient si la maintenance suit.
Surveillance et durcissement autour des permissions
Limiter les accès aux éditeurs et auteurs, c’est central, mais ce n’est pas un dispositif isolé. Pour qu’un durcissement serve vraiment, il doit s’accompagner d’une capacité à détecter.
Sans entrer dans des outils précis, vous pouvez mettre en place une hygiène robuste autour de :
- la journalisation des actions de l’admin et des modifications de contenus la vérification régulière des comptes, surtout ceux qui ont des accès élevés la revue des plugins et des autorisations liées aux rôles
Quand un compte est compromis, les traces existent presque toujours quelque part. Le but n’est pas de tout verrouiller, c’est de réduire la durée entre “compromission” et “réaction”.
Cas d’usage : quand l’auteur ne doit pas pouvoir publier
Sur beaucoup de sites, le brouillon est un espace de travail. Il n’est pas conçu pour être une version accessible au public. Si vous autorisez l’auteur à publier, un compromis a un effet immédiat.
Un modèle plus sûr consiste à :
- laisser l’auteur créer et éditer ses brouillons laisser l’éditeur revoir et corriger faire publier par une personne dont les droits sont plus stricts, ou via un mécanisme de validation
Si vous ne pouvez pas changer tout le workflow, une alternative graduelle est de retirer d’abord la publication directe, puis d’observer pendant une semaine. Vous verrez vite si le processus de relecture fonctionne et si l’équipe se réorganise sans contourner.
Multisite, sous-sites et rôles : attention aux surprises
Si vous utilisez WordPress en mode multisite, les règles changent. Un rôle peut se comporter différemment selon le niveau de site et les capacités réseau. Dans ce contexte, limiter l’accès aux éditeurs et auteurs doit être fait avec prudence, car des droits peuvent être hérités ou appliqués différemment.
Sur multisite, le risque n’est pas seulement “un contenu mal publié”. C’est aussi la capacité à toucher à la configuration réseau, voire à des éléments partagés. Si votre environnement est en multisite, je vous conseille de ne pas appliquer les restrictions sans une phase de test ciblée, car le comportement “attendu” peut différer de ce que vous avez vu en site simple.
Contrôle des comptes : l’autre moitié de la sécurité
Même avec des rôles bien réglés, un compte mal géré finit par ruiner la politique. Les éditeurs et auteurs sont souvent des comptes “humains”, liés à des équipes, des prestataires, des cycles de travail.
Quelques principes simples, qui changent vraiment la donne, sont :
- désactiver rapidement les accès quand une personne change de rôle ou quitte l’équipe forcer des mots de passe uniques et un second facteur si c’est possible dans votre organisation vérifier périodiquement la liste des comptes ayant des droits plus élevés que ceux du workflow
Je sais que ce sont des règles “banales” sur le papier, mais en pratique elles évitent la situation où vous optimisez les permissions sur le long terme, pendant qu’un ancien prestataire conserve un compte actif.
Pour bien faire : une mini check “avant après” (sans blabla)
Quand vous pensez avoir renforcé vos permissions, la meilleure méthode reste de comparer “avant” et “après” sur des cas concrets. Testez avec un compte éditeur et un compte auteur, sur un petit périmètre, puis observez.
Voici les trois points les plus rentables à vérifier :
- est-ce que l’auteur peut publier, directement ou indirectement, sans passer par validation ? est-ce que l’éditeur peut modifier des options ou des réglages globaux via les pages d’administration et ceux des plugins ? est-ce que certains actions restent possibles en accédant à des URL connues, même si l’interface ne les propose pas ?
Si vous obtenez des réponses satisfaisantes sur ces trois axes, vous avez déjà fait un gros saut de sécurité.
Conclusion ouverte sur votre politique, pas sur une version WordPress
Renforcer la sécurité WordPress en limitant l’accès aux éditeurs et auteurs, ce n’est pas une opération ponctuelle, c’est une décision de gouvernance technique. Vous fixez qui peut faire quoi, vous liez cette règle à votre workflow, puis vous vérifiez que WordPress et vos plugins respectent réellement cette frontière.
Le meilleur signe que votre durcissement fonctionne, c’est la stabilité opérationnelle : l’équipe publie sans tâtonner, et l’escalade de droits devient difficile. Dans un monde où les comptes peuvent être compromis, la séparation des privilèges est une protection qui ne dépend pas de la chance. Elle dépend de ce que vous avez choisi, une fois, et de ce que vous maintenez ensuite.