Réserver

Rôles et capacités WordPress : le guide pour gérer les accès sans risque

par Francis Rozange | Oct 2, 2026 | WordPress

A row of glass keys of different sizes, only the largest one glowing

À l’automne 2025, des attaquants ont tenté des dizaines de milliers de fois de s’ouvrir un compte administrateur sur des sites WordPress qui ne les avaient jamais invités. Il suffisait d’envoyer le formulaire d’inscription d’un plugin en ajoutant à la requête un seul champ : le rôle souhaité, « administrator ». Le plugin l’acceptait sans discuter.

Cette histoire résume le sujet de ce guide. Dans WordPress, tout accès se décide par des rôles et des capacités. Quand ce mécanisme est bien compris, il protège le site sans effort. Quand il est mal utilisé, par un plugin, par un développeur pressé ou par un administrateur trop généreux, il ouvre la porte en grand.

Vous trouverez ici les rôles par défaut et ce qu’ils permettent réellement, les capacités à connaître par leur nom, la façon dont WooCommerce ajoute les siens, la bonne manière de créer un rôle dans le code, le cas des mots de passe d’application, puis une méthode d’audit et de départ d’un prestataire, commandes à l’appui.

Rôles et capacités : les deux mots qui comptent

Un rôle est une liste nommée de capacités

Une capacité est un droit élémentaire : publier un article, téléverser un fichier, installer un plugin. Un rôle est simplement un nom posé sur une liste de capacités. L’éditeur, par exemple, réunit toutes les capacités nécessaires pour gérer les contenus de tous les auteurs.

Il n’existe aucun héritage entre les rôles dans le code. Le manuel des API communes présente les rôles comme une hiérarchie, chaque rôle reprenant les droits du précédent. Il décrit ainsi les listes par défaut, et la documentation des rôles précise même qu’aucun rôle ne doit être tenu pour supérieur à un autre. Chaque rôle est une liste à plat : retirer une capacité à l’auteur ne la retire pas à l’éditeur.

Le code ne devrait jamais vérifier un rôle. La documentation de current_user_can() déconseille de tester un nom de rôle à la place d’une capacité, parce que le résultat peut être peu fiable. On demande « cet utilisateur peut-il modifier cet article ? », jamais « est-il éditeur ? ».

Où WordPress les enregistre

Les définitions de rôles vivent dans une seule option de la base, wp_user_roles avec le préfixe par défaut. Les rôles attribués à chaque utilisateur, et les éventuelles capacités ajoutées à titre individuel, sont rangés dans sa méta wp_capabilities. Sur un multisite, chaque site a ses propres clés : le site principal garde le préfixe de base, les suivants prennent un préfixe numéroté, comme wp_2_.

Le super administrateur fait exception : il ne figure pas dans la liste des rôles. C’est une option du réseau, site_admins, qui contient une liste d’identifiants de connexion. Cette distinction compte au moment d’auditer un réseau, comme le détaille notre guide WordPress Multisite.

Les anciennes clés level_0 à level_10 survivent dans les définitions de rôles pour la compatibilité. Les niveaux d’utilisateur sont obsolètes depuis WordPress 2.0, et WordPress signale, en mode débogage, tout code qui vérifie encore un niveau numérique.

Les six rôles par défaut, du super administrateur à l’abonné

La documentation officielle décrit six rôles. Cinq existent sur un site simple ; le sixième, le super administrateur, n’apparaît que sur un multisite. À l’installation, WordPress crée automatiquement un compte administrateur, et le rôle donné aux nouveaux inscrits se règle dans Réglages, Général.

  • Super administrateur : administre le réseau entier, crée et supprime les sites, gère les plugins et les thèmes pour tous.
  • Administrateur : accès à toutes les fonctions d’administration d’un site, des réglages aux plugins en passant par les comptes.
  • Éditeur : publie et gère tous les contenus, y compris ceux des autres, modère les commentaires et gère les catégories.
  • Auteur : publie et gère ses propres articles, et téléverse des médias.
  • Contributeur : écrit et modifie ses propres articles, sans pouvoir les publier ni téléverser de fichier.
  • Abonné : ne gère que son profil.

Ces descriptions courtes cachent des différences importantes. L’auteur peut téléverser des fichiers, le contributeur non : un détail qui compte quand vous ouvrez un compte à un rédacteur externe. L’éditeur dispose en outre d’une capacité que beaucoup ignorent, traitée plus bas, qui lui permet de publier du code.

Site simple ou multisite : ce que perd l’administrateur

Sur un site simple, l’administrateur est de fait un super administrateur. Sur un multisite, il perd une série de capacités réservées au réseau : mettre à jour le cœur, les plugins et les thèmes, installer ou supprimer des plugins et des thèmes, modifier leurs fichiers, créer, modifier ou supprimer des comptes, et publier du HTML non filtré.

Cette coupure est voulue. Sur un réseau, l’administrateur d’un site est traité comme un utilisateur non fiable vis-à-vis des autres sites. Il gère ses contenus et ses réglages, mais ne peut rien faire qui toucherait le réseau entier.

Les capacités à connaître par leur nom

Une cinquantaine de capacités composent les rôles par défaut. Inutile de les apprendre toutes. Une dizaine suffisent pour comprendre ce qu’un compte peut réellement faire, et pour repérer un réglage dangereux dans un plugin d’édition de rôles.

unfiltered_html : pourquoi un éditeur peut publier du JavaScript

La capacité unfiltered_html permet de publier du HTML, et même du JavaScript, dans les articles, les pages et les widgets, sans que WordPress ne le nettoie. Sur un site simple, l’administrateur et l’éditeur l’ont par défaut. Sur un multisite, seul le super administrateur la possède.

La conséquence est rarement mesurée. L’équipe de sécurité de WordPress considère qu’un éditeur qui insère du JavaScript utilise une fonction prévue, pas une faille. Donner le rôle d’éditeur à quelqu’un revient donc à lui confier la possibilité d’exécuter du code dans le navigateur de vos visiteurs, et de vos administrateurs.

Si personne n’a besoin de cette possibilité, une constante la retire à tous, administrateurs compris :

define( 'DISALLOW_UNFILTERED_HTML', true );

Publier, modifier, téléverser

publish_posts donne accès au bouton de publication ; sans elle, un compte ne produit que des brouillons soumis à relecture. edit_others_posts permet de modifier les contenus des autres, et sert aussi à gérer les modèles dans l’éditeur de site. upload_files ouvre la médiathèque et le téléversement.

Réglages, plugins, apparence

manage_options ouvre les pages de réglages de WordPress, et la plupart de celles des plugins. Depuis WordPress 7.0, elle donne aussi accès à l’écran des connecteurs, où sont rangées les clés d’API des services d’IA, masquées à l’écran mais non chiffrées en base. install_plugins permet d’ajouter des plugins, ce qui revient à exécuter n’importe quel code sur le serveur.

edit_theme_options donne accès aux menus, aux widgets, à l’outil de personnalisation et à l’éditeur de site. La documentation précise qu’elle ne se limite pas à l’éditeur de site : c’est une capacité large, à ne pas distribuer à la légère.

Le trio de la gestion des comptes

list_users permet de voir la liste des comptes. promote_users active le menu de changement de rôle, et ne dépend pas de edit_users. Cette dernière permet de modifier les comptes, et c’est la plus sensible : le code du cœur rappelle que, sans filtrage, quiconque la possède peut faire d’un autre compte un administrateur.

Une subtilité de plus : sur un site simple, WordPress traite comme super administrateur tout utilisateur qui possède delete_users. Ajouter cette capacité à un rôle personnalisé lui donne donc le statut de super administrateur partout où le code appelle is_super_admin().

Capacités primitives et méta-capacités : comment WordPress tranche

Les capacités vues jusqu’ici sont dites primitives : elles sont enregistrées dans les rôles. Mais le code demande souvent autre chose, par exemple current_user_can( 'edit_post', $post_id ). Cette capacité, edit_post au singulier, n’existe dans aucun rôle : c’est une méta-capacité.

La fonction map_meta_cap() la traduit en capacités primitives selon le contexte. Pour modifier un article dont vous êtes l’auteur, il faut edit_posts ; s’il est publié, edit_published_posts en plus ; s’il appartient à un autre, edit_others_posts. Elle ne vérifie rien elle-même : elle dit ce qu’il faut posséder, puis WordPress compare avec les droits du compte.

Ce mécanisme est la raison pour laquelle les contrôles doivent toujours porter sur l’objet précis. Vérifier edit_posts ne dit pas si un utilisateur peut modifier tel article ; vérifier edit_post avec son identifiant, si.

Le piège de l’auto-modification

Une règle de map_meta_cap() autorise chaque utilisateur à modifier son propre compte. En 2016, le plugin User Role Editor l’a appris à ses dépens : il protégeait une action sensible en vérifiant edit_user sur un identifiant fourni par la requête. En passant son propre identifiant, n’importe quel inscrit franchissait le contrôle et pouvait obtenir le rôle d’administrateur.

Le correctif a remplacé ce contrôle par la capacité générale edit_users. La leçon reste valable : une méta-capacité répond à la question posée, pas forcément à celle que le développeur avait en tête.

Les rôles ajoutés par les plugins : l’exemple de WooCommerce

Un plugin peut créer ses propres rôles et ajouter des capacités aux rôles existants. WooCommerce en est l’exemple le plus répandu : à l’installation, il crée les rôles customer et shop_manager, que l’interface française appelle client et gestionnaire de boutique, et ajoute à l’administrateur et au gestionnaire ses propres capacités, comme manage_woocommerce.

Ce que peut faire un gestionnaire de boutique

Le gestionnaire de boutique gère les produits, les commandes, les codes promo et les réglages de WooCommerce. Il dispose aussi de presque tous les droits d’un éditeur sur les contenus, de l’import et de l’export, de la liste des comptes et de edit_theme_options. Il n’a pas manage_options, ni unfiltered_html, ni le droit d’installer des plugins.

Pour les comptes, WooCommerce lui donne edit_users au moment de l’exécution, puis en limite strictement l’usage : il ne peut modifier que des clients, et ne peut attribuer que le rôle de client. Ces garde-fous disparaissent si WooCommerce est désactivé, avec le droit lui-même. C’est un rôle solide pour un client qui gère sa boutique, à condition de ne pas le prendre pour un accès en lecture seule.

Le compte client et la porte d’admin-ajax

Le rôle client ne possède que read, comme un abonné. WooCommerce y ajoute à la volée des droits limités sur ses propres commandes : les voir, les payer, les annuler. Il redirige aussi les clients qui tentent d’ouvrir l’administration vers leur espace « Mon compte ».

Cette redirection n’apporte aucune protection. Elle exclut volontairement admin-ajax.php et admin-post.php, par lesquels passent de nombreuses actions de plugins. Chaque action doit donc vérifier elle-même les capacités. Le cas réel qui suit montre ce qui arrive quand ce n’est pas fait.

Enfin, supprimer WooCommerce ne supprime pas ses rôles, sauf si la constante WC_REMOVE_ALL_DATA est activée dans le fichier de configuration. Des rôles de plugins disparus traînent ainsi sur beaucoup de sites anciens.

Une porte de verre verrouillée contournée par un fin rayon passant par une ouverture latérale

Le cas réel : quand un formulaire d’inscription distribuait des comptes administrateur

King Addons for Elementor est un plugin d’éléments pour le constructeur Elementor, installé sur plus de dix mille sites. Il propose, entre autres, un formulaire de connexion et d’inscription. La faille CVE-2025-8489, notée 9,8 sur 10, documentée par Wordfence et par la base américaine NVD, est un cas d’école de mauvaise gestion des rôles.

Un champ de trop dans une requête

Le formulaire d’inscription envoyait ses données à admin-ajax.php. Le code de traitement faisait pourtant beaucoup de choses correctement : il refusait l’inscription si le site ne l’autorisait pas, vérifiait un jeton de sécurité, limitait le nombre de tentatives et nettoyait les champs reçus.

Puis il lisait un champ user_role dans la requête, avec « subscriber » comme valeur par défaut, et le transmettait tel quel à wp_insert_user(). Cette fonction applique le rôle qu’on lui donne, sans juger. Il suffisait donc d’ajouter user_role=administrator à la requête pour créer un compte administrateur.

Les protections présentes n’y pouvaient rien. Le nettoyage d’un champ garantit qu’il contient une chaîne propre, pas que cette chaîne est autorisée. Le jeton de sécurité, imprimé sur un formulaire public, prouve seulement que la requête vient de la page, pas que son auteur a le moindre droit. Toutes les versions de 24.12.92 à 51.1.14 étaient touchées.

Un correctif discret, une exploitation immédiate

Le 24 juillet 2025, un chercheur, Peter Thaleikis, signale la faille au programme de primes de Wordfence. Les clients payants de Wordfence reçoivent une règle de pare-feu le 4 août, les utilisateurs gratuits le 3 septembre, après le délai habituel de trente jours. L’éditeur publie la version corrigée 51.1.35 le 25 septembre.

Le journal des modifications de cette version parle d’améliorations de sécurité dans l’ensemble du plugin, sans mentionner d’élévation de privilèges. Aucun propriétaire de site ne pouvait y lire une urgence. La faille est rendue publique le 30 octobre 2025. Cette version ne réglait pas tout non plus : une autre élévation de privilèges sans authentification, CVE-2025-6325, touchait encore King Addons jusqu’à la version 51.1.36.

Selon Wordfence, les attaques commencent dès le lendemain, puis deviennent massives les 9 et 10 novembre. Début décembre, son pare-feu avait bloqué plus de 48 400 tentatives d’exploitation. Le signe à chercher sur un site touché : de nouveaux comptes administrateur, inconnus de l’équipe.

Avec un tel compte, un attaquant peut téléverser un plugin ou un thème contenant une porte dérobée, ou modifier les contenus pour rediriger les visiteurs. Le correctif tient en trois lignes : une liste blanche des rôles autorisés, limitée à « subscriber » et « customer », avec un retour à « subscriber » pour toute autre valeur.

Le même schéma, la même saison

Quelques semaines plus tôt, le plugin WP Freeio, fournie avec un thème premium de place de marché de services, présentait la même erreur : son code d’inscription recopiait le rôle envoyé par le formulaire. Le correctif est sorti le 9 octobre 2025, la faille a été publiée le lendemain, et les attaques ont commencé le jour même. Deux plugins différents ont commis la même faute, et chacun a été attaqué au plus tard le lendemain de la publication de sa faille.

Ce que WordPress 7.0 a changé

L’attaque contre King Addons supposait une condition : que le réglage « Tout le monde peut s’inscrire » soit actif. C’était la première vérification du code vulnérable. Un site qui n’avait pas besoin d’inscriptions publiques et les avait fermées n’était pas exposé.

WordPress 7.0, sorti en mai 2026, a retiré les rôles administrateur et éditeur de la liste « Rôle par défaut de tout nouveau compte ». Il a aussi ajouté à la Santé du site une alerte critique quand l’inscription est ouverte avec un rôle par défaut privilégié. Une valeur déjà enregistrée reste toutefois affichée et active.

Ces changements n’auraient pas arrêté King Addons, qui laissait la requête imposer n’importe quel rôle, quel que soit le rôle par défaut. Ils rappellent cependant la bonne question : votre site a-t-il vraiment besoin d’inscriptions ouvertes ? Pour aller plus loin, la feuille de route de la 7.2 prévoit d’empêcher qu’un rôle dangereux soit enregistré comme rôle par défaut ; la modification était encore en discussion début octobre 2026. Notre analyse des vulnérabilités WordPress en chiffres montre à quel point les failles de contrôle d’accès dominent les attaques.

Créer un rôle personnalisé proprement dans le code

add_role() à l’activation, pas à chaque chargement

Un rôle créé par add_role() est enregistré en base dès le premier appel. Les appels suivants ne font rien : la documentation de référence conseille donc de modifier les rôles à l’activation du plugin plutôt qu’à chaque chargement de page, et le manuel des plugins prévient qu’une recréation des rôles sans condition dégrade nettement les performances. Voici un exemple assemblé à partir des fonctions officielles :

register_activation_hook( __FILE__, 'acme_add_roles' );
function acme_add_roles() {
	// The list form needs WordPress 6.9 or later.
	add_role( 'acme_reviewer', 'Relecteur', array( 'read', 'edit_posts', 'edit_others_posts' ) );
}

Depuis WordPress 6.9, les capacités peuvent être passées sous forme de simple liste. Sur une version antérieure, utilisez des paires 'capacité' => true. Une valeur false refuse explicitement une capacité au rôle.

Modifier un rôle existant

Piège classique : add_role() ne met jamais à jour un rôle qui existe déjà. Elle ne fait rien et renvoie null. Pour ajouter ou retirer une capacité, passez par get_role(), puis add_cap() ou remove_cap(), dans une routine de mise à jour versionnée qui ne s’exécute qu’une fois :

add_action( 'plugins_loaded', 'acme_update_roles' );
function acme_update_roles() {
	if ( '2' === get_option( 'acme_roles_version' ) ) {
		return;
	}
	$role = get_role( 'acme_reviewer' );
	if ( $role ) {
		$role->add_cap( 'upload_files' );
	}
	update_option( 'acme_roles_version', '2' );
}

Dans un formulaire public, ne lisez jamais le rôle dans la requête : imposez-le, ou choisissez-le dans une liste blanche fixée dans le code, comme le fait désormais King Addons. Côté administration, pour proposer une liste de rôles, utilisez get_editable_roles(), que le filtre editable_roles permet de restreindre.

Nettoyer à la désinstallation

Désactiver un plugin ne retire pas ses rôles. Le nettoyage définitif se fait à la désinstallation, dans un fichier uninstall.php ou avec register_uninstall_hook(), en appelant remove_role(). Sans cela, les rôles d’un plugin supprimé restent dans la base, parfois avec des capacités que plus personne ne surveille.

Pour remettre les rôles par défaut dans leur état d’origine, WP-CLI propose wp role reset, qui ne touche pas aux rôles personnalisés. Le manuel des plugins déconseille en revanche de supprimer les rôles administrateur et super administrateur ; pour tout autre rôle par défaut retiré, il demande de garder le code de suppression en place, car une mise à jour de WordPress pourrait le recréer.

Les plugins d’édition de rôles

Quand vous devez ajuster des capacités sans écrire de code, un plugin d’édition de rôles fait l’affaire. Les principaux, tous actifs et compatibles avec WordPress 7.1 en octobre 2026, ont chacune leur point fort.

  • User Role Editor : plus de 700 000 installations, édition des capacités par cases à cocher, capacités par utilisateur, rôles multiples. Version Pro à partir de 29 dollars par an.
  • Members : gratuite, avec le refus explicite d’une capacité, le clonage de rôles et un lien de secours envoyé par courriel pour retrouver le rôle d’administrateur.
  • PublishPress Capabilities : sauvegarde automatique de chaque changement, ce qui permet de revenir en arrière, et masquage d’éléments de l’interface. Version Pro à partir de 69 dollars par an.
  • Advanced Access Manager : une gestion des accès par règles, plus puissante et plus complexe. Sa compatibilité déclarée s’arrêtait à WordPress 7.1.0 début octobre.

Ces plugins sont des outils d’administration installés en production, donc une surface d’attaque à part entière. User Role Editor a corrigé au moins trois failles d’élévation de privilèges, en 2016, en décembre 2024 et en septembre 2026 ; dans la dernière, un compte disposant de promote_users pouvait s’attribuer le rôle d’administrateur. Une fois les rôles réglés, rien n’oblige à garder le plugin actif.

Pour tester un rôle, User Switching permet de prendre l’identité d’un compte sans connaître son mot de passe, puis de revenir au sien. Pour garder une trace des changements de rôle, un plugin de journal comme WP Activity Log ou Simple History enregistre qui a modifié quoi, et quand.

Les mots de passe d’application : une clé avec tous les droits

Depuis WordPress 5.6, chaque compte peut créer des mots de passe d’application depuis son profil. Ils servent aux outils externes qui passent par l’API REST ou XML-RPC : une application mobile, un service d’automatisation, un agent d’IA. Ils ne permettent pas de se connecter à l’administration par le formulaire habituel.

Leur point faible tient en une phrase : un mot de passe d’application agit avec toutes les capacités du compte auquel il appartient. Il n’existe pas, dans le cœur, de mot de passe limité à la lecture. Un mot de passe créé sur le compte d’un administrateur pour un service quelconque est donc une clé d’administrateur, qui ne passe pas par la double authentification.

La bonne pratique en découle : créez un compte dédié pour chaque service, avec le rôle le plus bas qui suffit, et générez le mot de passe depuis ce compte. Ce point devient pressant avec les agents d’IA, comme l’explique notre guide sur l’IA dans WordPress et l’Abilities API.

Les désactiver ou les restreindre

Si aucun service n’en a besoin, un filtre les désactive pour tout le site :

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Un second filtre permet de les réserver à certains comptes, par exemple à ceux qui gèrent les réglages :

add_filter( 'wp_is_application_passwords_available_for_user', function ( $available, $user ) {
	return $available && user_can( $user, 'manage_options' );
}, 10, 2 );

La feuille de route de WordPress 7.2 prévoit un courriel d’alerte à la création d’un mot de passe d’application. Ce n’est pas encore disponible : en attendant, l’audit reste manuel.

Auditer les comptes et les rôles avec WP-CLI

L’audit en cinq minutes

La ligne de commande donne en quelques secondes ce que l’interface oblige à chercher écran par écran. Ces quatre commandes couvrent l’essentiel : la liste des administrateurs, les capacités ajoutées à un compte en dehors de son rôle, le contenu d’un rôle, et la liste des rôles présents sur le site. Seule réserve : l’option --origin=user lit la clé wp_capabilities telle quelle, et ne renvoie donc rien avec un autre préfixe de tables ou sur un site secondaire d’un multisite.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user list-caps 12 --origin=user
wp cap list editor
wp role list

Cherchez un administrateur que personne ne reconnaît, une capacité sensible ajoutée à un compte isolé, un rôle de plugin disparu. Pour les mots de passe d’application, wp user application-password list suivi du compte affiche ceux qui existent, avec leur date de dernière utilisation. Notre sélection de commandes WP-CLI essentielles détaille les options utiles.

Quand l’écran des comptes ment

En septembre 2026, Wordfence a décrit un logiciel malveillant installé comme extension indispensable. Il crée un administrateur au nom anodin, puis le masque de l’écran des comptes et de l’API REST, et va jusqu’à corriger les compteurs affichés. Selon Wordfence, interroger directement la base est la manière fiable de voir ce compte.

wp user list passe par la même mécanique de requête que l’écran des comptes, et les extensions indispensables restent chargées même avec l’option qui désactive les plugins. La commande wp db query s’exécute en revanche avant le chargement des plugins. Cette requête en lecture seule liste les administrateurs tels qu’ils sont en base ; vérifiez d’abord le préfixe avec wp db prefix :

wp db query "SELECT u.ID, u.user_login, u.user_email, u.user_registered FROM wp_users u JOIN wp_usermeta m ON m.user_id = u.ID WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%'"

Si cette liste diffère de celle de wp user list, considérez le site comme compromis tant que l’écart n’est pas expliqué, et appliquez d’abord les mesures de notre guide pour sécuriser WordPress.

Le moindre privilège pour les agences et leurs clients

Une personne, un compte nominatif, le rôle le plus bas qui suffise

Le principe du moindre privilège, tel que le définit le NIST, consiste à ne donner à chacun que les droits nécessaires à sa fonction. L’OWASP ajoute un point souvent oublié : vérifier régulièrement que les droits ne s’accumulent pas avec le temps.

Appliqué à WordPress, cela donne quelques règles simples. Un compte par personne, jamais de compte partagé, pour que les journaux et la réattribution des contenus aient un sens. Un administrateur nommé par technicien de l’agence. Pour l’équipe du client, l’éditeur ou le gestionnaire de boutique plutôt que l’administrateur. Et une élévation temporaire retirée dès la fin de l’intervention.

Le guide officiel de durcissement ajoute deux mesures : éviter les identifiants évidents comme « admin », qui sont attaqués en premier, et ajouter la double authentification à un mot de passe fort. La constante DISALLOW_FILE_EDIT retire en outre à tous les comptes l’éditeur de fichiers intégré.

La liste de départ d’un prestataire

Quand un prestataire ou un collaborateur s’en va, l’ordre des opérations compte. Couper l’accès sans fermer les sessions laisse une porte ouverte jusqu’à leur expiration.

  1. Fermer ses sessions en cours, pour que ses connexions actives tombent immédiatement.
  2. Supprimer ses mots de passe d’application, qui survivraient sinon à un simple changement de mot de passe.
  3. Rétrograder ou supprimer le compte, en réattribuant ses contenus à un autre compte.
  4. Changer les accès partagés hors de WordPress : hébergement, SFTP, DNS, services tiers.
  5. Renouveler les clés de sécurité du fichier de configuration si le doute subsiste, ce qui déconnecte tout le monde.
  6. Relancer l’audit des administrateurs, par WP-CLI et par la base.
wp user session destroy jdupont --all
wp user application-password delete jdupont --all
wp user delete jdupont --reassign=3
wp config shuffle-salts

L’option --reassign est essentielle : sans elle, WP-CLI demande une confirmation puis supprime les contenus du compte. Ses articles et ses pages partent à la corbeille, mais ses médias, comme la plupart de ses autres types de contenus, sont effacés définitivement. Sur un multisite, supprimer un compte depuis un site le retire seulement de ce site : le compte du réseau subsiste, avec ses mots de passe d’application.

Tableau récapitulatif

Rôle ou outil Ce qu’il permet Risque principal Usage conseillé
Administrateur Tout, plugins et comptes compris Exécution de code sur le serveur Comptes nominatifs, double authentification
Éditeur Tous les contenus, HTML non filtré JavaScript publié dans les pages Responsables éditoriaux de confiance
Auteur, contributeur Ses propres contenus Faible, téléversement pour l’auteur Rédacteurs, externes en contributeur
Gestionnaire de boutique WooCommerce, contenus, clients Apparence, import et export Équipe du client qui gère la boutique
Abonné, client Son profil, ses commandes Actions de plugins mal protégées Seul rôle acceptable pour une inscription publique
Mot de passe d’application L’API avec les droits du compte Clé complète, hors double authentification Compte dédié par service, rôle minimal
Plugin d’édition de rôles Capacités sans code Surface d’attaque en production Régler, puis désactiver

Questions fréquentes

Puis-je donner à un éditeur l’accès aux plugins ?

Techniquement oui, en lui ajoutant activate_plugins ou install_plugins. Mais installer un plugin revient à exécuter du code sur le serveur : ce compte devient de fait un administrateur. Mieux vaut un second compte administrateur nominatif, protégé par la double authentification.

Le rôle de gestionnaire de boutique convient-il à un client ?

Oui, c’est souvent le meilleur choix pour l’équipe qui gère les commandes et les produits. Il n’accède ni aux réglages généraux ni aux plugins. Gardez en tête qu’il peut modifier l’apparence, importer des contenus et éditer les comptes clients.

Faut-il ouvrir les inscriptions ?

Seulement si le site en a besoin, pour une boutique, un espace membre ou un forum. Dans ce cas, le rôle par défaut doit être abonné, ou client pour WooCommerce. La faille de King Addons, par exemple, ne fonctionnait que si l’inscription était ouverte. Pour les sites d’adhésion, notre comparatif des plugins d’adhésion WordPress aide à choisir un outil sérieux.

Les mots de passe d’application contournent-ils la double authentification ?

Oui, par conception : ils servent à l’API, qui ne passe pas par le formulaire de connexion. Le plugin Two Factor, publié par WordPress.org, ferme au moins la porte au mot de passe principal : pour un compte protégé par la double authentification, il n’accepte par défaut sur l’API que ses mots de passe d’application. Le filtre two_factor_user_api_login_enable permet de modifier ce comportement.

Comment réparer un administrateur privé de ses droits ?

Si vous avez retiré par erreur des capacités au rôle administrateur, wp role reset administrator le remet dans son état d’origine. La commande retire aussi les capacités ajoutées par les plugins : sur une boutique, rétablissez celles de WooCommerce avec « Réinitialiser les permissions », dans WooCommerce, État, Outils. Sans ligne de commande, le plugin Members, s’il était déjà actif, envoie par courriel un lien de secours qui rend le rôle d’administrateur.

Conclusion

Les rôles de WordPress sont simples : des listes de capacités, rangées dans une option et une méta. Le danger vient de ce qu’on en fait. Un éditeur qui peut publier du JavaScript, un mot de passe d’application créé par un administrateur, un rôle lu dans une requête publique, un compte de prestataire oublié : chacun de ces détails suffit à livrer un site entier.

Retenez trois réflexes. Vérifiez des capacités sur des objets précis, jamais des noms de rôles. Donnez à chaque personne et à chaque service le rôle le plus bas qui suffise. Et auditez régulièrement les administrateurs, y compris directement en base.

Sources

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, et développe ses propres plugins. Parlons de votre projet WordPress.

Francis Rozange

Ancien chef de rubrique à Libération, il dirige LaFactory, agence web internationale depuis 1996.

Panier