# Un audit de sécurité d’un WordPress headless a révélé un wp-admin resté public > L'équipe front avait totalement oublié wp-admin, resté accessible sans restriction sur un projet censé être « invisible » côté back. Ce que cet oubli a coûté. - Auteur : Clément Hadrot - Publié le : 2024-11-18 - Mis à jour le : 2024-11-18 - Catégorie : Headless & API - URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/audit-securite-wordpress-headless-wp-admin-public/ ## L’essentiel - Un projet headless donne parfois l'illusion trompeuse que le back-office WordPress est invisible donc protégé - Un wp-admin exposé reste une cible d'attaque par force brute, quelle que soit l'architecture du front - Restreindre l'accès par IP ou par authentification HTTP reste la protection la plus simple et la plus fiable « De toute façon, personne ne voit jamais WordPress sur ce projet, tout passe par l'API ». Cette phrase, prononcée en réunion de lancement par un chef de projet convaincu de bien faire, résume assez bien un raisonnement dangereux qui s'est répété sur plusieurs projets headless observés ces dernières années : l'idée que l'invisibilité apparente du back-office pour le visiteur final équivaudrait à une forme de protection. Sur ce projet précis, un site e-commerce de matériel de sport consommant WordPress via l'API REST, l'audit de sécurité programmé six mois après la mise en ligne a révélé que `/wp-admin` et `/wp-login.php` restaient parfaitement accessibles publiquement, sans aucune restriction d'accès, exactement comme sur n'importe quel WordPress classique. ## Ce que l'audit a trouvé En consultant les journaux d'accès du serveur hébergeant WordPress, l'auditeur a découvert plus de 40 000 tentatives de connexion sur `wp-login.php` au cours des trois semaines précédentes, provenant de dizaines d'adresses IP différentes, un schéma classique d'attaque par force brute automatisée. Aucune de ces tentatives n'avait réussi, un plugin de limitation des tentatives de connexion étant heureusement actif, mais la charge générée sur le serveur par ce trafic parasite représentait à elle seule près de 15 % de la consommation CPU quotidienne mesurée, un coût d'hébergement facturé pour rien. Plus préoccupant encore : un compte utilisateur avec un rôle d'administrateur, créé pour un ancien prestataire et jamais désactivé, utilisait un mot de passe généré automatiquement mais vieux de plus de deux ans, sans authentification à deux facteurs. Ce compte n'a heureusement montré aucun signe de compromission lors de l'audit, mais représentait une porte d'entrée bien réelle, totalement indépendante de l'architecture headless du site. ## Pourquoi cet oubli est si fréquent sur les projets headless Le raisonnement erroné vient d'une confusion entre deux notions distinctes : l'absence d'affichage public du thème WordPress (puisque le front est entièrement pris en charge par une autre application) et l'absence d'exposition réseau du back-office d'administration. La première n'a strictement aucune influence sur la seconde. WordPress, même utilisé en pur mode API, conserve son interface d'administration complète, accessible à la même adresse que sur n'importe quelle installation classique, avec les mêmes risques d'attaque par force brute, les mêmes vulnérabilités potentielles de plugins installés, et les mêmes enjeux de gestion des comptes utilisateurs. > L'essentiel à retenir : Un projet headless donne parfois l'illusion trompeuse que le back-office WordPress est invisible donc protégé ; Un wp-admin exposé reste une cible d'attaque par force brute, quelle que soit l'architecture du front ; Restreindre l'accès par IP ou par authentification HTTP reste la protection la plus simple et la plus fiable Sur les projets headless, l'attention de l'équipe se porte presque exclusivement sur la sécurisation de l'API (authentification des requêtes en écriture, configuration CORS, limitation du taux de requêtes), au point d'oublier que le back-office lui-même reste un point d'entrée classique qu'il faut sécuriser exactement comme sur un site WordPress traditionnel. ## Le correctif appliqué - Restriction de l'accès à `/wp-admin` et `/wp-login.php` par authentification HTTP basique au niveau du serveur web, en plus de l'authentification WordPress elle-même, une couche supplémentaire qui bloque l'essentiel du trafic automatisé avant même d'atteindre WordPress. - Audit complet des comptes utilisateurs existants, avec désactivation immédiate du compte de l'ancien prestataire et rotation de tous les mots de passe administrateur restants. - Activation de l'authentification à deux facteurs pour tous les comptes disposant d'un rôle d'administrateur ou d'éditeur, via un plugin dédié compatible avec les applications d'authentification standards (TOTP). - Mise en place d'une alerte automatique en cas de connexion réussie depuis une adresse IP inhabituelle, envoyée par e-mail à l'équipe technique. ``` # Extrait de configuration Nginx ajoutée location ~ ^/(wp-admin|wp-login\.php) { auth_basic "Zone restreinte"; auth_basic_user_file /etc/nginx/.htpasswd_admin; try_files $uri $uri/ /index.php?$args; } ``` ### Un compromis à documenter avec le client L'authentification HTTP supplémentaire impose une étape de connexion en plus pour toute personne devant accéder au back-office, y compris l'équipe éditoriale. Ce compromis a été présenté et validé explicitement avec le client, avec une liste d'adresses IP de bureau ajoutée en exception pour éviter cette friction aux utilisateurs internes réguliers, tout en la conservant pour tout accès externe. ## Ce que cet incident a changé dans la méthodologie Depuis cet audit, chaque nouveau projet headless suivi par l'équipe inclut désormais une checklist de sécurisation du back-office comme étape obligatoire de mise en ligne, distincte de la checklist de sécurisation de l'API. Les deux sont traitées comme deux surfaces d'attaque séparées, avec des responsables et des vérifications propres à chacune, plutôt que comme un seul et même sujet « sécurité headless » traité de façon globale et donc plus facilement incomplète. > L'architecture headless protège l'expérience du visiteur final d'un certain nombre de risques ; elle ne protège absolument pas le back-office WordPress, qui reste une cible à part entière tant qu'il existe et qu'il est joignable. ## En résumé Ce cas illustre un biais assez répandu chez les équipes qui découvrent le headless : l'idée que découpler le rendu du contenu équivaudrait à réduire la surface d'attaque du projet dans son ensemble. Un WordPress headless reste un WordPress, avec son back-office, ses comptes utilisateurs et ses plugins, et mérite exactement la même rigueur de sécurisation qu'un site classique, indépendamment de la sophistication du front qui le consomme.