Dans WordPress, les rôles sont pratiques, mais ils donnent aussi une fausse impression de maîtrise. Vous pouvez avoir l’impression d’avoir “limité” un utilisateur à l’édition de contenu, alors qu’il conserve des capacités trop larges pour votre modèle de risque. C’est particulièrement vrai avec les rôles Editor et Author, qui sont souvent attribués par confort, puis jamais revalidés.
Contrôler finement l’accès ne veut pas dire verrouiller tout le monde à mort. Cela veut dire comprendre ce que WordPress autorise réellement pour chaque rôle, là où vos plugins et thèmes viennent se brancher, et comment les actions “banales” peuvent devenir des portes d’entrée. La sécurité WordPress repose rarement sur une seule option. Elle se construit sur des choix cohérents, des vérifications régulières, et une réduction mesurée des permissions.
Pourquoi Editor et Author posent un problème de “permissions par défaut”
Le rôle Author est généralement associé à un besoin simple: publier ses articles, gérer ses propres contenus. En apparence, c’est cohérent.
Le rôle Editor est plus large: gérer, approuver, modifier la production éditoriale, souvent sur l’ensemble du site. C’est utile, mais c’est aussi un amplificateur de risque. Un Editor peut parfois faire plus que “relire”, surtout si votre site a des points d’extension (plugins, outils de formulaire, configurations spécifiques, types de contenus customisés).
Là où ça devient délicat, c’est que WordPress ne “pense” pas comme vous. Il applique un ensemble de capacités, qui évoluent selon:
- votre version, vos plugins, vos réglages, et parfois la façon dont vous avez créé vos contenus (par exemple, custom post types et taxonomies).
J’ai vu des scénarios très concrets, un peu frustrants, où un utilisateur “juste auteur” a pu injecter du contenu HTML plus risqué qu’attendu via des champs ou des blocks spécifiques, ou bien un Editor a pu créer des brouillons qui déclenchent des automatisations côté plugin (génération de pages, synchronisation, publication différée). Rien de magique, juste des chaînes d’actions.
Ce que vous voulez, c’est casser ces chaînes à la racine, au niveau des capacités, et compléter avec des garde-fous qui limitent ce que WordPress autorise même en cas d’erreur ou de compromission de compte.
Lire le rôle comme WordPress le lit: capacités, pas étiquettes
La plupart des gens pensent “Editor” ou “Author” comme des étiquettes fonctionnelles. WordPress, lui, travaille avec des capacités. Et c’est ce point qui compte.
Selon votre configuration, un rôle peut:
- publier ou seulement soumettre à relecture, modifier les pages ou uniquement certains types de contenus, uploader des médias, changer des paramètres liés aux thèmes et aux plugins, accéder à des écrans d’administration, interagir avec l’API REST.
Deux conséquences pratiques:
1) Deux sites peuvent donner des permissions très différentes à “Editor”, même si vous partez du même rôle par défaut, parce que vos plugins ajoutent souvent des capacités ou enregistrent des types de contenus.
2) Si vous ne vérifiez pas les capacités “réelles”, vous risquez de corriger le mauvais endroit. Par exemple, vous pouvez empêcher la publication, mais laisser la possibilité de modifier des éléments qui finissent quand même en page publique.
Le bon réflexe consiste à auditer les capacités effectives du rôle. On ne parle pas de théorie, mais de ce que WordPress accepte concrètement, rôle par rôle.
Le premier audit: repérer ce qui doit être impossible
Avant de toucher aux réglages, j’aime bien prendre cinq à dix minutes pour répondre à des questions simples. C’est un audit orienté “risques d’abus”.
- Qui doit pouvoir publier directement, et qui doit être bloqué en relecture? Qui doit pouvoir modifier des contenus existants, en particulier ceux créés par d’autres? Qui doit pouvoir uploader des fichiers (images, vidéos, documents) et dans quels contextes? Qui doit accéder aux zones sensibles (thèmes, plugins, réglages généraux, import/export)? Qu’est-ce qui, dans votre stack, pourrait transformer un contenu édité en action technique (par exemple via shortcodes, blocs, ou formulaires)?
Ce cadrage évite le piège classique: modifier les rôles “au feeling”, puis découvrir que vous avez retiré trop (retours en arrière), ou pas assez (mauvaise exposition).
Voici une façon pragmatique de procéder, sans se noyer dans des dizaines de paramètres.
- Vérifier les utilisateurs actuels qui sont en Editor et Author, et cartographier leurs besoins réels (publication, édition, médias). Inspecter les capacités effectives du rôle, surtout ce qui concerne l’édition des contenus, l’upload de médias et l’accès à des écrans d’administration. Examiner les plugins actifs pour repérer ceux qui ajoutent des permissions ou des interfaces d’édition (généralement, ceux liés aux formulaires, aux pages builder, au SEO, à la gestion de documents). Mesurer l’impact opérationnel: si vous retirez une capacité, qui va bloquer le flux éditorial et pourquoi?
Ce premier passage est souvent plus révélateur que n’importe quel bouton “désactiver”.
Verrouiller l’édition sans casser le travail: règles concrètes pour Editor
Pour un Editor, l’objectif est rarement de tout enlever. Dans la vraie vie, vous voulez garder:
- la coordination éditoriale, la capacité à gérer la mise en forme, et la production de contenus qui respectent votre ligne éditoriale.
Mais vous voulez empêcher les actions qui ouvrent des chemins latéraux: modifications de réglages, installation de composants, édition de fichiers, et permissions de publication trop directes.
Une approche cohérente consiste à imposer des garde-fous autour de trois axes.
Publication et contrôle de validation
Si votre équipe fonctionne avec relecture systématique, un Editor ne devrait pas publier en direct partout. L’idée n’est pas de punir, mais de créer un “mur” entre création et exposition.
Dans beaucoup de cas, le meilleur compromis est de laisser Editor gérer et préparer, puis exiger la validation. Vous pouvez obtenir ce résultat en ajustant les capacités liées à la publication. Le réglage exact dépend de la manière dont vous gérez les états de contenu (draft, pending review, etc.) Et des types de contenus impliqués.
Modification de contenus des autres
Un Editor peut être autorisé à corriger, mais pas forcément à réécrire librement n’importe quel contenu. Si vous avez des auteurs multiples, je vous recommande de décider explicitement:
- soit vous lui donnez une autorité éditoriale globale, soit vous le limitez à la relecture et la gestion de catégories ou d’éléments, sans ouvrir une capacité de modification totale.
Ce point évite le scénario classique où un utilisateur “trop fiable” s’autorise à changer des pages critiques.
Accès aux écrans d’administration et capacités techniques
Les zones “réglages”, “plugins” et “thèmes” sont rarement nécessaires pour un travail éditorial. Même si WordPress ne rend pas toujours l’accès visible au ressenti, des capacités de type gestion de plugin, gestion de thème, ou édition de fichiers (selon le contexte) peuvent exister si quelqu’un a ajouté des privilèges au fil du temps.
C’est ici qu’une bonne configuration se voit, parce que vous éliminez des chemins qui ne sont pas ceux du métier.
Author: réduire l’exposition sans enlever la capacité de produire
Le rôle Author est le plus sensible au modèle “compte compromis”. Un attaquant qui obtient un compte Author a moins de leviers qu’avec un Editor, mais il peut tout de même:
- publier du contenu malveillant si la publication est autorisée, injecter des éléments via médias ou blocs, abuser de fonctionnalités d’intégration côté plugins.
Le point de départ: décider si Author doit publier directement ou uniquement soumettre.
Soumission à relecture comme premier verrou
Dans beaucoup de sites, faire passer Author en “soumission à relecture” est un excellent compromis. Vous conservez la fluidité pour créer, tout en imposant un contrôle humain avant diffusion.
Il y a un détail important: sur certains sites, des équipes publient vite. Si vous imposez la relecture à tout le monde, vous créez un goulot et vous risquez de voir des contournements, par exemple donner les droits “Editor” à des personnes qui auraient juste besoin de publier régulièrement.
La solution n’est pas “aucune publication”. La solution, c’est de calibrer: quels auteurs doivent pouvoir publier directement, sur quels types de contenus, et dans quel périmètre.
Médias: images utiles, fichiers dangereux
Pour Author, l’upload de médias peut être normal. Mais laissez-vous suffisamment de contrôle? Les images posent rarement problème. Les fichiers, documents et formats inattendus le sont davantage.
Même sans entrer dans des scénarios extrêmes, je recommande de:
- limiter les types de fichiers que vous autorisez, filtrer ce que vos plugins de médias acceptent, et vérifier que vos champs liés aux médias ne donnent pas accès à une mise en page HTML trop permissive.
Si vous utilisez des blocs ou un éditeur riche, testez le résultat rendu. Ce n’est pas l’upload qui est dangereux en soi, c’est ce que le site finit par exposer publiquement.
Le rôle n’est pas tout: ce que les plugins changent dans le jeu
Le point que beaucoup sous-estiment: les plugins peuvent transformer la surface d’attaque. Un rôle “correct” dans WordPress peut rester “trop large” une fois que des extensions ajoutent:
- des shortcodes avec paramètres, des pages builder accessibles, des formulaires front qui déclenchent des actions, ou des endpoints REST.
La sécurité ne consiste pas à bannir les plugins. Elle consiste à comprendre leurs interactions avec les rôles.
Un exemple courant: un plugin de formulaires permet à certains utilisateurs de modifier les formulaires, d’autres de publier les pages associées, et d’autres encore de gérer les entrées. Si votre Author peut accéder à l’édition des formulaires sans contrôle, vous lui donnez un levier inattendu, même s’il ne touche pas “les réglages”.
Le bon réflexe est simple, mais demande de l’attention: à chaque nouveau plugin, revalider les permissions sur Editor et Author. Une fois par mois en interne, ou avant un changement majeur, c’est souvent raisonnable.
Garde-fous techniques complémentaires (sans paranoïa)
Contrôler les rôles est central. Mais il y a des couches complémentaires qui réduisent l’impact d’une mauvaise attribution de capacité ou d’une compromission de compte.
Éviter l’édition de fichiers depuis l’admin
Sur beaucoup de sites, l’édition de fichiers via l’interface WordPress (éditeur de thèmes et plugins) n’est pas nécessaire. La désactiver réduit une classe de risques qui, sinon, reste offerte à des rôles trop privilégiés.
Selon votre configuration et vos contraintes de maintenance, vous pouvez adopter une posture “administration stricte”: pas d’édition en ligne, déploiement via votre méthode habituelle (FTP, Git, CI/CD).
Couper des surfaces d’attaque inutiles
Si vous n’utilisez pas l’XML-RPC, ou certaines fonctionnalités d’accès distante, les réduire aide. Mais attention: certains plugins peuvent en dépendre, notamment pour des intégrations d’outils externes. Donc, on ne change pas à l’aveugle. On teste.
Sécuriser l’accès authentifié
Les rôles ne protègent pas si le compte est facile à usurper. Sur un site éditorial, c’est fréquent: mots de passe réutilisés, absence de contrôle d’appareil, ou comptes laissés en place après un départ.
La meilleure amélioration, souvent, vient d’un cocktail:
- mots de passe solides et uniques, verrouillage en cas d’essais répétés (selon la stack), journalisation des connexions, et authentification à deux facteurs pour les rôles sensibles.
Vous n’avez pas besoin de tout durcir, mais vous devez traiter Editor comme “sensibilité élevée”.
Mettre les capacités au bon niveau: exemples de permissions à revoir
Quand on veut “contrôler l’accès”, il faut savoir quoi contrôler. Les catégories qui reviennent le plus dans les audits Editor et Author sont souvent celles qui touchent à la publication, à l’édition et à l’infrastructure.
Voici des exemples de capacités à vérifier, car elles déterminent ce que l’utilisateur peut faire même si vous croyez qu’il est limité.
Publier des articles (directement ou uniquement soumis à validation) Modifier les articles d’autrui (portée et types de contenus) Gérer les médias (upload, suppression, parfois édition) Accéder à des écrans d’administration liés aux thèmes, plugins ou réglages Modifier des types de contenus customisés (si vos plugins en dépendent)Le piège, c’est de croire que “l’éditeur éditorial” n’accède qu’à l’éditeur visuel. Une capacité mal calibrée peut donner accès à des écrans ou actions qu’on n’imaginerait pas.
Workflow éditorial: un réglage de permissions qui a un coût
Il y a une vérité terrain: chaque verrouillage a un coût humain. Si vous mettez Author en relecture systématique, votre équipe doit absorber le temps de validation. Si vous retirez trop de capacités à Editor, la relecture devient lente, et les gens contournent.
C’est là que la “sécurité” devient un arbitrage, pas une case à cocher.
J’ai déjà vu une équipe forcer le modèle inverse: plutôt que d’ajuster les capacités d’Author, ils ont fini par donner le rôle Editor à des auteurs réguliers, parce que ça “allait plus vite”. Résultat: plus de surface d’attaque, plus de risque si un compte se fait compromettre.
La solution consiste à calibrer des règles adaptées à votre réalité:
- certains auteurs publient en direct sur des types de contenus non critiques, d’autres sont en relecture, Editor gère la qualité et l’assemblage éditorial, pas l’administration globale.
Ce n’est pas plus compliqué, juste mieux pensé.
Une méthode de durcissement progressive, sans rupture
Si vous devez corriger un site en production, l’erreur classique consiste à tout changer d’un coup. WordPress peut réagir de façon non intuitive dès que des plugins ou des contenus customisés sont impliqués.
Je recommande un plan en trois temps, avec tests ciblés.
Préparer un environnement de test ou une fenêtre de maintenance courte, puis modifier un seul rôle à la fois (commencer par Author). Tester avec un utilisateur test réel sur les scénarios éditoriaux quotidiens, publication, brouillon, modification d’un contenu existant, et gestion des médias si nécessaire. Surveiller les logs et les comportements inattendus pendant les 24 à 72 heures après la mise en place. Documenter le “pourquoi” pour chaque capacité modifiée, parce qu’au bout de quelques mois, vous ne vous rappellerez plus de vos arbitrages. Enfin, ajuster le rôle Editor et réévaluer les plugins qui touchent à l’édition, car c’est souvent eux qui font basculer les permissions.Cette progression limite les surprises et réduit le risque d’affecter le contenu déjà publié.
Cas limites: types de contenus custom, multisite, et REST API
Trois situations reviennent souvent.
Types de contenus customisés
Si vos plugins créent des “post types” spécifiques, un rôle peut ne pas avoir accès par défaut, ou au contraire obtenir des droits implicites via des réglages plugin. Vérifiez aussi:
- les états (draft, pending review), la capacité à publier, et la capacité à modifier des éléments existants.
Multisite
En multisite, les rôles peuvent avoir un comportement différent, selon la configuration. L’objectif reste le même, mais les pouvoirs varient, et les administrateurs de site ont une place particulière.
Accès REST et endpoints
Même si votre rôle ne touche pas l’admin, il peut agir via l’API, selon ce que votre stack autorise. Si votre site expose des endpoints et que des plugins ajoutent des actions éditoriales, l’accès REST https://gardewp.fr/securite-wordpress/ devient un sujet de sécurité WordPress à part entière.
Dans ces cas, l’audit doit être plus “systémique”. On ne corrige pas seulement le tableau des rôles. On vérifie les chemins réels d’exécution.
Checklist de validation finale avant de dire “c’est bon”
Avant de considérer que Editor et Author sont “contrôlés”, validez des choses qui se voient dans l’usage réel. Les tests doivent ressembler au travail quotidien, sinon vous aurez un faux sentiment de sécurité.
- Essayez de publier, puis observez si le contenu passe en relecture ou s’il devient public immédiatement. Modifiez un contenu créé par quelqu’un d’autre avec Author, puis confirmez le comportement attendu. Testez l’upload de médias, y compris les formats que votre équipe utilise vraiment. Vérifiez l’accès aux pages d’administration pertinentes, sans confondre “invisible” et “interdit”. Contrôlez un ou deux scénarios plugin critiques, par exemple génération de pages, formulaires, ou shortcodes liés à l’édition.
À ce stade, vous pouvez être plus serein.
Ce que j’aurais fait différemment sur des sites “trop ouverts”
Il y a un schéma que je rencontre souvent en audit: les rôles ont été donnés pour accélérer, puis le site a grandi, et l’équipe n’a pas revalidé les hypothèses. Le résultat, c’est une dérive. Un Editor qui a fini par faire des choses qui n’étaient pas prévues au départ, ou un Author qui peut publier plus facilement que ce que l’organisation tolère.
Le bon indicateur, ce n’est pas “est-ce que ça marche aujourd’hui”. C’est plutôt:
- “Si un compte est compromis, qu’est-ce que l’attaquant peut faire en une heure?” “Est-ce que le pire scénario est borné?” “Est-ce qu’on peut détecter vite et réagir?”
Contrôler l’accès aux rôles Editor et Author n’est pas une formalité. C’est une décision de sécurité qui impacte la manière dont votre contenu arrive en ligne, et la façon dont vous gérez la confiance entre personnes et systèmes.
Si vous voulez, dites-moi votre contexte (site mono ou multisite, plugins principaux liés à l’édition, et si Author doit publier directement ou passer en relecture). Je peux vous proposer une matrice de capacités cible, adaptée à votre workflow, sans casser vos opérations.