Une agence partenaire nous confie un test d’intrusion externe sur cinq sites WordPress qu’elle gère pour des clients dans des secteurs sans rapport les uns avec les autres — une clinique vétérinaire, un cabinet de recrutement, une boutique de vêtements, une association culturelle, un cabinet comptable. Les cinq sites ont été développés à des périodes différentes, par des personnes différentes, sur des hébergeurs différents. Et pourtant, en fin de mission, un constat s’impose : les mêmes trois erreurs de configuration reviennent, sous des formes légèrement différentes, sur les cinq sites sans exception.
Ce n’est pas une coïncidence statistique isolée. C’est le reflet d’habitudes de développement répandues dans l’écosystème WordPress, transmises d’un projet à l’autre sans jamais être remises en question, et qui méritent d’être nommées précisément pour qu’une agence puisse les intégrer à sa propre checklist de recette avant livraison.
Erreur récurrente n°1 : des comptes utilisateurs avec des identifiants prévisibles
Sur les cinq sites, quatre utilisaient encore un nom d’utilisateur administrateur strictement identique au nom de l’agence ou une variante triviale (« admin », « agence-nom »), une pratique héritée du modèle de développement initial jamais reconsidérée au moment de la livraison au client final. Un identifiant prévisible ne constitue pas une faille en soi, mais il réduit de moitié le travail d’un attaquant menant une attaque par force brute ou credential stuffing : il ne lui reste plus qu’à deviner le mot de passe, sans avoir à deviner ou énumérer l’identifiant associé.
# Vérification rapide via WP-CLI sur chaque site du portefeuille
wp user list --role=administrator --field=user_loginLe correctif ne demande aucune compétence technique particulière : renommer les comptes administrateurs avec des identifiants non prévisibles, sans lien avec le nom de l’agence, du client ou de fonctions génériques.
Erreur récurrente n°2 : des messages d’erreur ou informations de débogage exposés
Sur trois des cinq sites, une configuration de développement oubliée exposait des informations techniques en production : sur l’un, WP_DEBUG_DISPLAY resté actif révélait des chemins serveur au moindre avertissement PHP ; sur un autre, un fichier phpinfo.php déposé « temporairement » pour diagnostiquer un problème de configuration des mois auparavant restait accessible publiquement, exposant la configuration complète du serveur ; sur le troisième, le fichier readme.html par défaut de WordPress, jamais supprimé, confirmait la version exacte installée à quiconque prenait la peine de le consulter.
Chacun de ces trois cas relève d’un principe commun : un fichier ou un réglage utile en développement, jamais retiré au passage en production, devient une source d’information gratuite pour la reconnaissance d’un attaquant potentiel.
Erreur récurrente n°3 : des permissions de fichiers trop larges sur le serveur
Sur les cinq sites, l’analyse des permissions du système de fichiers via un accès SSH accordé pour l’audit a révélé, dans au moins un dossier sensible de chaque installation, des permissions 777 — lecture, écriture et exécution pour tous les utilisateurs du système, y compris ceux sans aucun lien avec le site concerné sur un hébergement mutualisé. Ce réglage, souvent appliqué par un développeur pressé pour résoudre un problème ponctuel d’écriture refusée (par exemple lors d’une mise à jour qui échouait faute de droits), est presque toujours resté en place bien après que le problème initial a été résolu autrement, ou aurait pu l’être.
# Recherche de permissions excessives sur l'ensemble d'une installation
find /var/www/exemple.fr -type d -perm 0777
find /var/www/exemple.fr -type f -perm 0777La correction standard restreint les dossiers à 755 et les fichiers à 644, à l’exception du seul dossier wp-content/uploads qui nécessite une écriture par le processus PHP, sans jamais justifier une ouverture à l’exécution ni à l’écriture par des utilisateurs système tiers.
Ce que cette synthèse révèle sur la nature réelle du risque
Aucune des trois erreurs récurrentes de ce pentest ne constitue, prise isolément, une vulnérabilité spectaculaire ou une faille zero-day. Ce sont des négligences de configuration, individuellement mineures, mais dont l’accumulation sur un même site — un identifiant prévisible, combiné à une divulgation d’information, combinée à des permissions trop larges — augmente significativement la surface d’attaque réelle et la facilité d’exploitation en cas de tentative sérieuse.
C’est précisément ce profil de risque, fait de petites négligences cumulées plutôt que d’une faille unique et dramatique, qui caractérise la majorité des sites WordPress d’agence que nous auditons : la sophistication n’est presque jamais nécessaire côté attaquant quand la base n’a pas été correctement nettoyée avant mise en ligne.
Le retour transmis à l’agence partenaire a été sans détour : « vos cinq sites n’ont pas cinq problèmes différents, ils ont le même processus de mise en production incomplet, répété cinq fois ». La correction structurelle proposée n’a donc pas porté sur chaque site individuellement, mais sur la checklist de recette elle-même.
Pour aller plus loin
Cette synthèse ne prétend pas remplacer une méthodologie complète de test d’intrusion professionnel, qui couvre un périmètre bien plus large (authentification, logique métier, configuration réseau) et suit un cadre structuré propre à chaque prestataire. Elle illustre en revanche un constat pratique utile à toute équipe qui livre des sites WordPress en série : une checklist de mise en production commune, appliquée sans exception, aurait suffi à éliminer les trois erreurs les plus fréquemment rencontrées ici, avant même qu’un audit externe ne soit nécessaire pour les révéler.
