# Mots de passe d’application : sécuriser l’API REST sans exposer le principal > Depuis WordPress 5.6, les mots de passe d'application évitent de confier votre mot de passe principal à une appli tierce. Voici comment les mettre en place proprement. - Auteur : Clément Hadrot - Publié le : 2021-12-15 - Mis à jour le : 2021-12-15 - Catégorie : Sécurité - URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/mots-de-passe-application-api-rest/ ## L’essentiel - Un mot de passe par usage, révocable individuellement à tout moment - Généré depuis le profil utilisateur, jamais choisi à la main - Compatible avec l'authentification HTTP Basic de l'API REST Pendant des années, connecter une application mobile ou un script à l'API REST de WordPress imposait un choix inconfortable : soit on créait un compte dédié avec un mot de passe faible « pour faire simple », soit on donnait le mot de passe principal d'un compte administrateur à une extension tierce. Les deux options laissaient une porte grande ouverte en cas de fuite. WordPress 5.6, sorti en décembre 2020, a réglé ce problème avec les mots de passe d'application. Le principe est simple mais change vraiment la donne : chaque application ou service reçoit son propre mot de passe, généré aléatoirement, utilisable uniquement pour l'authentification à l'API, et révocable à tout moment sans toucher au mot de passe du compte. Voyons comment les utiliser correctement, ce qu'ils protègent réellement, et les limites à connaître. ## Pourquoi ne plus jamais partager son mot de passe principal Un mot de passe principal donne accès à tout : la connexion à l'administration, la récupération de compte, parfois même d'autres services si l'utilisateur le réemploie ailleurs. Le confier à une application tierce revient à lui donner les clés de la maison entière pour qu'elle puisse simplement relever le courrier. Si cette application est compromise, mal codée, ou si son fournisseur subit une fuite de données, c'est l'intégralité du compte WordPress qui tombe. Les mots de passe d'application changent cette logique : ils n'ouvrent qu'une porte de service, celle de l'API REST authentifiée en HTTP Basic. Ils ne permettent pas de se connecter à l'écran de connexion classique de `wp-login.php`. Un mot de passe d'application compromis reste gênant, mais son impact est circonscrit et réversible en un clic. ## Créer un mot de passe d'application depuis le profil La génération se fait dans l'administration, sur la page de profil de l'utilisateur concerné, dans la section **Mots de passe d'application**. Il suffit de saisir un nom explicite, par exemple « Application mobile de suivi de commandes » ou « Script de synchronisation stock », puis de cliquer sur **Ajouter un nouveau mot de passe d'application**. WordPress génère alors une chaîne aléatoire affichée une seule fois : il faut la copier immédiatement, elle ne sera plus jamais visible ensuite. > L'essentiel à retenir : Un mot de passe par usage, révocable individuellement à tout moment ; Généré depuis le profil utilisateur, jamais choisi à la main ; Compatible avec l'authentification HTTP Basic de l'API REST ### Bonnes pratiques de nommage et de granularité - Un nom par usage réel, jamais un nom générique comme « app » ou « test » - Un mot de passe distinct par intégration, même si plusieurs services appartiennent au même prestataire - Une revue régulière de la liste, pour repérer les entrées oubliées ou obsolètes Cette granularité a un intérêt immédiat : si un audit de logs montre une activité suspecte associée à un nom précis, il suffit de révoquer ce seul mot de passe, sans perturber les autres intégrations ni forcer tous les utilisateurs à se reconnecter. ## Utiliser le mot de passe dans une requête Côté client, l'authentification se fait en HTTP Basic, avec le login WordPress comme nom d'utilisateur et le mot de passe d'application comme mot de passe. WordPress ignore les espaces qu'il affiche dans le mot de passe généré, mais il est plus sûr de les conserver tels quels pour éviter toute confusion. ``` curl https://exemple.fr/wp-json/wp/v2/posts \ -u "editeur:abcd efgh ijkl mnop qrst uvwx" \ -X POST \ -H "Content-Type: application/json" \ -d '{"title":"Article créé via l'\''API","status":"draft"}' ``` Ce mécanisme fonctionne uniquement si le site est servi en HTTPS. En clair, envoyer un mot de passe d'application sur une connexion non chiffrée reviendrait à le diffuser en clair sur le réseau, ce qui annule tout l'intérêt de la démarche. ## Révoquer et surveiller La révocation se fait en un clic depuis la même page de profil : chaque mot de passe d'application affiche sa date de création et sa dernière utilisation, ce qui permet de repérer une entrée dormante ou, à l'inverse, une entrée utilisée à une heure ou depuis une adresse inattendue. Cette date de dernière utilisation est précieuse pour détecter un usage anormal sans avoir à mettre en place un système de journalisation externe. > Sur les projets où je livre une intégration tierce, je crée systématiquement le mot de passe d'application avec le client présent, pour qu'il comprenne où et comment le révoquer le jour où l'intégration change de prestataire. ## Ce que les mots de passe d'application ne remplacent pas Ils ne dispensent pas de vérifier les capacités côté serveur : un utilisateur avec un rôle Contributeur qui génère un mot de passe d'application reste limité aux capacités de son rôle, ce qui est cohérent, mais mérite d'être gardé en tête lors de la conception d'une intégration. Ils ne remplacent pas non plus un contrôle `permission_callback` rigoureux sur les routes personnalisées de l'API REST : l'authentification prouve qui appelle, l'autorisation décide de ce qu'il a le droit de faire, ce sont deux étapes distinctes. Enfin, un hébergeur peut désactiver cette fonctionnalité via le filtre `wp_is_application_passwords_available`, par exemple sur un multisite où l'on souhaite centraliser l'authentification ailleurs. Il est utile de vérifier que ce filtre n'est pas déjà modifié par une extension avant de partir du principe que la fonctionnalité est disponible. ## En résumé Les mots de passe d'application referment une vraie faille de sécurité qui existait depuis les débuts de l'API REST : la nécessité de partager un mot de passe principal pour connecter une application tierce. Un mot de passe par usage, révocable individuellement, journalisé avec sa date de dernière utilisation : c'est un progrès simple, disponible depuis WordPress 5.6, et qu'il serait dommage de ne pas adopter systématiquement sur tout projet qui expose l'API REST à des services externes.