Auditez les accès WordPress avant qu'un ancien compte ne devienne un problème actuel
Accordez aux personnes et intégrations les droits nécessaires à leur travail. Vérifiez séparément les mots de passe d'application et leur révocation, sans bloquer le propriétaire.

Sur cette page
Un audit des accès WordPress doit répondre à deux questions : qui peut modifier le site, et quels outils externes peuvent agir par l'intermédiaire de ces comptes ? Une liste de collaborateurs ne répond qu'à la première. Un ancien identifiant d'intégration peut rester pertinent après que la personne qui l'a créé a cessé de se connecter.
Commencez par une copie restaurable du site et un compte administrateur confirmé sous le contrôle du propriétaire. Examinez ensuite les comptes nominatifs, leurs capacités réelles et leurs mots de passe d'application. Ce guide suppose une installation WordPress classique sur un seul site. Multisite, les produits d'abonnement et les extensions de gestion des rôles peuvent modifier ce modèle : vérifiez les droits réels, pas seulement l'intitulé du rôle.
Partez de la tâche, pas du rôle le plus commode
La documentation des rôles et capacités décrit les groupes de droits par défaut. Un Contributeur peut rédiger et gérer ses articles, sans les publier ; un Auteur peut publier ses propres articles ; un Éditeur peut gérer ceux des autres. Un Administrateur dispose de pouvoirs plus larges sur le site. Ces différences comptent lorsqu'un prestataire doit uniquement soumettre un brouillon.
Pour chaque compte, décrivez la tâche actuelle en une phrase. « Dépose le rapport hebdomadaire pour validation éditoriale » est plus utile que « marketing ». Comparez cette tâche aux actions permises. Si les rôles standards ne conviennent pas, définissez le besoin avant d'installer ou modifier une extension de rôles, puis testez les capacités obtenues plutôt que de vous fier à leur nom.
Ne partagez pas une connexion administrateur pour éviter de créer un utilisateur. Un compte nominatif permet de retirer l'accès d'une personne sans distribuer volontairement un nouveau mot de passe à tous les autres. Maintenez une voie de récupération contrôlée par le propriétaire, afin que le départ d'une agence ou d'un prestataire ne supprime pas aussi le seul accès permettant d'administrer le site.
Testez un rôle moins privilégié avec des tâches représentatives : enregistrer un brouillon, envoyer les médias nécessaires, modifier le contenu prévu et tenter une action qui doit être interdite. Un Contributeur standard ne peut pas téléverser de fichiers. Un flux nécessitant des images demande donc un ajustement réfléchi. Répondez au besoin précis, pas à toutes les demandes futures imaginables en accordant l'administration.
Inventoriez les mots de passe d'application séparément
Le guide d'authentification de l'API REST décrit les mots de passe d'application pour un accès authentifié à l'API via HTTPS. Ils sont distincts du mot de passe habituel de l'utilisateur. Leur intérêt opérationnel est de donner à une intégration son propre identifiant, plutôt que le mot de passe utilisé au quotidien par la personne.
Consignez le compte propriétaire de chaque identifiant, le service qui l'utilise, son responsable et la nécessité actuelle de la connexion. Un nom descriptif aide à reconnaître son usage ; il ne limite pas, à lui seul, les requêtes autorisées. Alignez les droits du compte de service sur le travail réellement accompli par l'intégration.
Le guide d'intégration des mots de passe d'application explique leur gestion et leur révocation. Utilisez un identifiant distinct par connexion pour que le retrait d'un outil ne casse pas toutes les autres intégrations du même utilisateur. Ne collez pas ces mots de passe dans une feuille d'audit, un message de support ou un ticket public : documentez le responsable et l'usage, pas le secret.
Si le responsable d'une intégration est inconnu, enquêtez avant de supprimer à l'aveugle. Identifiez la tâche de publication, de sauvegarde ou de synchronisation associée et trouvez son responsable. Inconnu ne signifie pas inoffensif, mais ne signifie pas non plus inutilisé. L'audit doit transformer l'incertitude en décision explicite : conserver, remplacer ou révoquer.
Révoquez les accès dans un ordre maîtrisé
Pour un départ prévu, identifiez d'abord ce qui doit continuer : publications programmées, propriété des contenus, gestion des médias et intégrations. Transférez la responsabilité opérationnelle et créez les identifiants de remplacement depuis le compte autorisé. Confirmez leur fonctionnement avant de retirer un identifiant nécessaire à un service maintenu.
En cas de compromission présumée, donnez la priorité au confinement et au processus de gestion d'incident plutôt qu'à une transmission de routine. Ce guide est une revue des accès, pas une garantie de réponse à incident. Préservez les éléments pertinents et impliquez l'administrateur ou le spécialiste de sécurité lorsque l'enquête dépasse le nettoyage ordinaire des comptes.
Pour un nettoyage classique, révoquez le mot de passe d'application choisi, confirmez que l'ancienne connexion ne s'authentifie plus et vérifiez que les autres intégrations fonctionnent. Réduisez ou retirez ensuite l'accès interactif de la personne selon le besoin. Un clic ne prouve pas la révocation ; les preuves utiles sont la requête refusée attendue et le processus indépendant toujours opérationnel.
Avant de supprimer un utilisateur, examinez les conséquences sur ses contenus et leur attribution, puis choisissez délibérément toute réaffectation nécessaire. Ne transformez pas une suppression d'accès en suppression éditoriale accidentelle. Les principes de notre guide WordPress sur la préproduction et le retour arrière sont utiles lorsqu'une extension de rôles ou une autre configuration est modifiée.
Gardez un registre assez léger pour être entretenu
Conservez une entrée par utilisateur et une entrée liée par intégration : usage, responsable, rôle ou capacités, date de revue et décision. Stockez les secrets dans le système de gestion approuvé par l'équipe, pas à côté de l'inventaire lisible. Ce registre doit permettre à un successeur de comprendre le site sans lui fournir tous les secrets par défaut.
Déclenchez explicitement une revue à la fin d'un contrat, lors d'un changement de fonctions ou au retrait d'un outil. Une vérification périodique peut révéler des oublis, mais un départ ne doit pas attendre le prochain rappel. Ajoutez ce processus à la routine de maintenance du site, avec une personne nommément chargée de le mener à terme.
À la fin, testez les deux côtés du changement. L'éditeur conservé doit pouvoir accomplir le travail prévu ; le compte ou l'identifiant retiré doit échouer sur l'action désormais interdite. Consignez le test et son résultat sans prétendre que cela démontre la sécurité du site entier.
Un audit utile laisse moins de privilèges inexpliqués, pas nécessairement moins de comptes. Des comptes distincts et justifiés peuvent être plus faciles à gérer qu'une poignée de connexions administrateur partagées. L'objectif est de rendre chaque autorisation active défendable et chaque autorisation retirée effectivement absente.
Traduit de l’édition source en anglais.
Sources primaires
- documentation des rôles et capacitéswordpress.org
- guide d'authentification de l'API RESTdeveloper.wordpress.org
- guide d'intégration des mots de passe d'applicationmake.wordpress.org


