Qu’est-ce qui reste d’un site WordPress après cinq années de mises à jour ponctuelles, de changements d’extensions et de passages de prestataires successifs, sans qu’aucune revue de sécurité dédiée n’ait jamais été menée ? La réponse tient rarement en une seule faille spectaculaire. Elle ressemble plutôt à un empilement de petites négligences, chacune anodine prise isolément, mais qui forment ensemble une surface d’attaque bien plus large que ce que le propriétaire du site imagine.
Reprendre un projet dans cet état, à l’occasion d’un audit ou d’une reprise de maintenance, révèle des motifs récurrents. Les classer permet de prioriser une remise à niveau au lieu de traiter chaque symptôme séparément.
Les extensions désactivées mais jamais supprimées
Une extension désactivée depuis wp-admin reste sur le serveur, dans le dossier wp-content/plugins, avec l’intégralité de son code PHP accessible via une requête directe si son fichier principal n’inclut pas de vérification defined('ABSPATH'). Pire : certaines extensions enregistrent des routes REST ou des points d’entrée AJAX qui restent actifs tant que le fichier PHP existe, même si l’extension n’apparaît plus comme active dans l’interface.
Un audit type commence systématiquement par un inventaire du dossier plugins comparé à la liste des extensions actives renvoyée par get_option('active_plugins'). L’écart entre les deux listes est presque toujours non nul sur un site de cinq ans.
Les comptes créés pour un besoin ponctuel
Un compte administrateur créé pour un audit externe, un stagiaire, un prestataire en mission de trois semaines : ces comptes survivent largement à leur raison d’être. La commande wp user list --role=administrator via WP-CLI suffit à faire apparaître, sur un site ancien, des comptes dont plus personne dans l’équipe ne se souvient de la fonction.
Les identifiants d’API jamais renouvelés
Une clé d’API générée en 2020 pour une intégration devenue obsolète reste souvent stockée en clair dans une option WordPress ou dans un fichier de configuration versionné par erreur. Sans rotation planifiée, ces identifiants ne sont jamais invalidés : ils continuent de fonctionner tant que le service tiers ne les révoque pas de son côté.
Ce que révèle une recherche ciblée
Une recherche du terme api_key ou secret dans la base de données via WP-CLI (wp db search 'api_key') fait souvent remonter des dizaines de résultats répartis entre options de plugins, métadonnées de configuration et parfois des exports de sauvegarde oubliés dans les téléversements.
Les fichiers de sauvegarde exposés publiquement
Un export SQL ou une archive complète du site, généré manuellement avant une migration et jamais supprimé, finit régulièrement dans wp-content/uploads ou à la racine du site, accessible par une simple URL directe si aucune règle serveur ne bloque l’accès aux extensions .sql, .zip ou .tar.gz.
- Fichiers
.sqllaissés par un export manuel via phpMyAdmin - Archives complètes générées par une extension de sauvegarde puis jamais nettoyées
- Copies de
wp-config.phprenommées en.baklors d’une modification rapide
Les correctifs de sécurité contournés plutôt que corrigés
Face à une alerte de sécurité sur une extension, la réaction la plus rapide consiste souvent à désactiver la fonctionnalité concernée plutôt qu’à mettre à jour ou remplacer l’extension. Cinq ans plus tard, ce contournement temporaire est devenu une configuration permanente que plus personne ne remet en question, et l’extension vulnérable est toujours installée, simplement inactive dans un coin.
Un audit qui ne trouve rien à signaler après cinq ans sans revue dédiée n’a probablement pas assez creusé : la dette de sécurité ne disparaît jamais d’elle-même, elle s’accumule silencieusement.
Notre verdict
Ces quatre catégories — extensions fantômes, comptes orphelins, identifiants jamais tournés, sauvegardes exposées — reviennent avec une régularité frappante sur les projets anciens. Aucune ne relève d’une vulnérabilité sophistiquée : ce sont des oublis cumulés, qui deviennent dangereux uniquement parce que personne n’a eu l’occasion de les regarder d’ensemble. La bonne nouvelle, c’est qu’un inventaire méthodique via WP-CLI et une recherche ciblée dans la base de données suffisent à en révéler l’essentiel en quelques heures, avant même d’entrer dans une analyse de code plus fine.
