Décembre 2020, WordPress 5.6 : les mots de passe d’application entrent dans le cœur, permettant à une intégration tierce de s’authentifier sur l’API REST sans partager le mot de passe principal du compte. Cinq ans plus tard, cette fonctionnalité reste largement utilisée pour connecter des services externes, des scripts d’automatisation, et plus récemment des agents IA — souvent sans que la question de la portée réelle de ces jetons ne soit jamais posée explicitement.
Le mécanisme natif de WordPress ne propose, à ce jour, aucune limitation de portée intégrée pour un mot de passe d’application : le jeton généré hérite intégralement des capacités du compte utilisateur auquel il est rattaché, sans distinction possible entre « ce compte peut tout faire » et « ce jeton ne devrait servir qu’à une seule tâche précise ».
Comment fonctionne réellement un mot de passe d’application
Techniquement, un mot de passe d’application est une chaîne générée via wp-admin/profile.php ou par programmation via WP_Application_Passwords::create_new_application_password(), associée à un compte utilisateur existant. Au moment de l’authentification, WordPress ne fait aucune distinction entre une requête effectuée avec le mot de passe principal du compte et une requête effectuée avec l’un de ses mots de passe d’application : les deux bénéficient exactement des mêmes capacités, celles du compte lui-même.
Cette conception, simple et efficace au moment de son introduction, suppose implicitement que chaque intégration dispose de son propre compte dédié avec un rôle restreint. Dans la pratique, de nombreux projets génèrent un mot de passe d’application directement depuis un compte administrateur existant, par simplicité au moment de la mise en place initiale.
Pourquoi la portée s’élargit avec le temps
Un compte créé avec un rôle restreint peut voir ses capacités élargies plus tard, pour une raison ponctuelle sans rapport avec l’intégration initiale : un nouveau plugin qui nécessite une capacité supplémentaire sur ce même compte, un changement de rôle décidé pour une autre intégration qui partage le même compte de service par commodité. Le mot de passe d’application généré des mois auparavant profite silencieusement de cet élargissement, sans qu’aucune notification n’attire l’attention sur ce changement de portée effective.
Ce qu’une bonne pratique de compartimentation change
- Un compte dédié par intégration, jamais partagé entre deux usages distincts
- Un rôle personnalisé listant explicitement les capacités nécessaires à cette intégration précise
- Un nom de mot de passe d’application descriptif, incluant la date de création et l’usage prévu
wp user create integration-facturation integration-facturation@exemple.test --role=facturation_lecture_seule
wp user application-password create integration-facturation "Export comptable mensuel"
Documenter la portée attendue, pas seulement le jeton
Un fichier de suivi, distinct du gestionnaire de mots de passe utilisé pour stocker le jeton lui-même, doit consigner pour chaque mot de passe d’application créé : le compte associé, les capacités attendues au moment de la création, et une date de révision prévue. Sans cette documentation, la question de la portée ne se pose littéralement jamais après la mise en place initiale.
La révocation d’un jeton compromis reste un sujet distinct
Cet article ne traite volontairement pas de la procédure à suivre en cas de compromission avérée d’un jeton, un cas d’urgence qui appelle une réaction immédiate plutôt qu’une révision planifiée. La question ici est différente : comment éviter que la portée d’un jeton parfaitement légitime ne s’élargisse silencieusement, faute de révision périodique, jusqu’à représenter un risque disproportionné par rapport à son usage réel.
Un mot de passe d’application créé il y a plus d’un an sans aucune révision documentée mérite d’être traité comme suspect par défaut, indépendamment de tout signe de compromission observé.
Pour aller plus loin
La portée d’un jeton d’application WordPress ne se réduit jamais spontanément : elle reflète à chaque instant les capacités du compte auquel il est rattaché, capacités qui n’évoluent, en pratique, que dans le sens d’un élargissement au fil des besoins ponctuels. Compartimenter chaque intégration derrière un compte dédié et planifier une révision périodique documentée restent les deux seules mesures qui empêchent réellement cette dérive silencieuse de s’installer durablement.
