Quatorze mois : c’est la durée pendant laquelle un mot de passe d’application, créé pour un contributeur externe d’un titre de presse locale, est resté parfaitement fonctionnel après la fin de sa collaboration avec la rédaction. Personne n’avait pensé à le révoquer, parce que personne ne savait précisément qu’il existait encore.
Le contributeur, journaliste indépendant, avait reçu ce jeton pour publier ses articles directement depuis un outil de rédaction externe connecté à l’API REST de WordPress. Sa collaboration terminée, son compte utilisateur avait été désactivé dans l’interface d’administration — mais le mot de passe d’application, lui, continuait de fonctionner sans restriction.
Un mot de passe d’application ne suit pas le statut du compte
Depuis leur introduction native en WordPress 5.6, les mots de passe d’application permettent d’authentifier des requêtes vers l’API REST sans exposer le mot de passe principal du compte. Ils sont stockés de façon chiffrée dans la méta utilisateur _application_passwords et restent associés au compte tant qu’ils ne sont pas explicitement révoqués, un par un, depuis l’écran de profil de l’utilisateur ou via l’API elle-même.
Ce qui a échappé à la rédaction : « désactiver un compte » signifie généralement changer son rôle vers un rôle sans droit de publication, voire le convertir en abonné. Mais tant que le compte lui-même n’est ni supprimé ni entièrement dépourvu de la capacité edit_posts, les mots de passe d’application déjà générés continuent de fonctionner sous ce nouveau rôle, ou pire, sous l’ancien si le changement de rôle a été mal appliqué.
Comment la fuite a été repérée
La découverte n’est pas venue d’une alerte de sécurité mais d’un article publié un dimanche soir, alors que la rédaction n’avait planifié aucune publication ce jour-là. L’article, bénin, a immédiatement mis la puce à l’oreille du rédacteur en chef, qui a demandé un audit des accès actifs.
- Le compte du journaliste externe existait toujours, avec un rôle « abonné » supposé inoffensif.
- Son mot de passe d’application, généré quatorze mois plus tôt, n’avait jamais été révoqué.
- Le rôle « abonné » avait été mal configuré et conservait la capacité
edit_postspar héritage d’une extension tierce.
Retrouver et révoquer les jetons actifs
La commande WP-CLI suivante permet de lister les mots de passe d’application actifs pour un utilisateur donné, sans passer par l’interface d’administration :
wp user application-password list 118 --format=table
+------+-------------------+---------------------+---------------------+
| uuid | name | created | last_used |
+------+-------------------+---------------------+---------------------+
| a1b2 | Outil rédaction | 2022-02-01 09:12:00 | 2023-04-02 21:47:00 |
+------+-------------------+---------------------+---------------------+
La colonne last_used a confirmé l’utilisation récente, alors même que la collaboration avait cessé bien avant. La révocation, elle aussi disponible en ligne de commande, a été appliquée immédiatement :
wp user application-password delete 118 a1b2
Corriger le rôle avant de corriger le symptôme
Révoquer le jeton isolé n’aurait réglé qu’une partie du problème. L’audit a montré que le rôle « abonné » du site conservait, par un ajout hérité d’une ancienne extension de commentaires jamais totalement désinstallée, la capacité edit_posts. Corriger le rôle lui-même, via remove_cap(), a évité que le même scénario ne se reproduise avec n’importe quel autre compte désactivé de la même façon.
Enseignement retenu de cet incident : désactiver un accès et révoquer un accès sont deux actions distinctes. La première change une étiquette, la seconde ferme réellement une porte.
Mettre en place un audit périodique
La rédaction a depuis instauré une revue trimestrielle de tous les mots de passe d’application actifs sur le site, croisée avec la liste des collaborateurs encore en activité. Cette revue, réalisée en quelques minutes via WP-CLI, ne remplace pas un processus de départ formalisé, mais elle rattrape les oublis que ce processus laisse inévitablement passer.
| Situation | Action attendue |
|---|---|
| Fin de collaboration d’un contributeur externe | Révoquer chaque mot de passe d’application associé |
| Changement de rôle d’un compte | Vérifier les capacités effectivement héritées |
| Compte inactif depuis plus de six mois | Auditer et révoquer les jetons non utilisés |
Notre verdict
Un mot de passe d’application est un accès à part entière, indépendant du mot de passe principal et du statut apparent d’un compte. Le considérer comme secondaire, ou supposer qu’un changement de rôle suffit à le neutraliser, revient à laisser une clé physique en circulation après avoir changé la serrure visible. Seule une révocation explicite, jeton par jeton, ferme réellement l’accès.
