Les fichiers cachés qui encombrent votre serveur WordPress et pourquoi cela compte

Ouvrez la racine de n’importe quel site WordPress ancien via SFTP et vous trouverez des fichiers qui ne devraient pas y être. De vieilles sauvegardes de développeur avec des noms comme functions24-02-2026.php. Des fichiers de test oubliés comme info.php. Des archives compressées d’installations précédentes. Des feuilles de calcul exportées par des extensions. Des dumps SQL laissés par une migration l’an dernier. Le site continue de fonctionner, alors personne ne les supprime, et ils s’accumulent.

La plupart sont un encombrement inoffensif. Certains sont de sérieux risques de sécurité et de SEO. Le problème, c’est que très peu de propriétaires de site regardent un jour, si bien que la frontière entre les deux est invisible. Cet article décrit les catégories les plus courantes, pourquoi certaines comptent, et comment auditer la racine régulièrement.

Copies de sauvegarde datées des fichiers du thème

Un audit récent sur le site d’une agence de Sydney avec laquelle nous avons travaillé en a révélé des dizaines. Le dossier du thème actif contenait functions24-02-2026.php, header31-01-2026.php, footer19-01-2026.php, 404-04-08-2025.php et une longue liste de fichiers frères datés de la même façon. Chacun était une sauvegarde de développeur créée avant une modification, pensée comme option de retour arrière locale, et jamais supprimée.

WordPress ne charge pas ces fichiers, ils n’affectent donc pas le comportement du site. Mais ils sont accessibles publiquement par leur URL. Quiconque devine le nom du fichier peut lire le code source de versions passées, qui peut contenir des identifiants, des chemins codés en dur ou des signatures de fonctions vulnérables. Ils rendent aussi chaque audit futur plus difficile, car ils encombrent le code de fichiers qui semblent réels mais ne le sont pas.

Le bon endroit pour les sauvegardes de code, c’est le contrôle de version, pas le serveur en production. Déplacez-les vers git et supprimez les copies datées.

Dumps SQL et archives de sauvegarde

Un fichier SQL contenant l’export de la base de données posé dans la racine est l’un des artefacts les plus dangereux d’un site WordPress. Si un attaquant le télécharge, il a votre table des utilisateurs, vos mots de passe hachés, vos clés secrètes via wp_options et l’ensemble du contenu. Il en va de même pour les archives compressées de sauvegarde du site complet.

Les fichiers de sauvegarde ne devraient jamais résider dans la racine. Ils doivent être hors site, dans un espace de stockage que le web public ne peut pas atteindre. Si vous trouvez une archive de sauvegarde dans la racine, supprimez-la immédiatement et vérifiez les journaux d’accès de votre hébergement pour tout téléchargement antérieur.

Copies de configuration comme wp-config.bak

L’erreur classique. Un développeur s’apprête à modifier la configuration. Il copie wp-config.php en wp-config.bak comme filet de sécurité. Il fait la modification. Il laisse la copie derrière lui. L’extension .bak n’est pas exécutée par PHP, donc le fichier est servi en texte brut. Tout attaquant qui essaie le nom évident a votre configuration complète, y compris les identifiants de base de données et les salts.

Ne laissez jamais une copie de wp-config sous quelque forme que ce soit sur le serveur en production. Utilisez le contrôle de version. Si vous devez copier, copiez vers un chemin hors de la racine et supprimez-le dès que le travail est terminé.

Fichiers de test et info.php

Beaucoup de développeurs créent un petit fichier info.php avec phpinfo pour confirmer la version de PHP sur un nouveau serveur, puis oublient de le supprimer. Le fichier reste accessible, et phpinfo déverse une énorme quantité de détails serveur que les attaquants peuvent exploiter pour préparer une attaque. Version de PHP, extensions chargées, chemins serveur, variables d’environnement, parfois davantage.

Tout fichier de test, aussi inoffensif qu’il paraisse, devrait être supprimé une fois son rôle rempli. info.php, test.php, hello.html, tout ce dont vous n’avez pas besoin sur le site public n’a rien à y faire.

Pages et dossiers qui masquent les URL WordPress

C’est le dangereux. Si un dossier existe sur le disque avec le même nom qu’une page WordPress, le serveur web résout d’abord le dossier. Le routage d’URL de WordPress n’a jamais l’occasion de traiter la requête. Le visiteur voit le contenu du dossier, pas la page WordPress.

Le cas de l’agence de Sydney que nous avons évoqué correspondait exactement à ce schéma. L’attaquant a créé cinq dossiers à la racine, nommés pour imiter de vraies pages WordPress. Les fichiers de ces dossiers interceptaient chaque requête vers ces URL et servaient du spam SEO masqué. Le propriétaire n’en avait aucune idée, car l’admin WordPress affichait toujours les pages d’origine, et une visite ordinaire de la page d’accueil paraissait normale.

Auditez la racine spécifiquement à la recherche de dossiers correspondant aux slugs de pages WordPress. Tout ce que vous ne pouvez pas expliquer est suspect.

Fichiers d’échange d’éditeur et répertoires de contrôle de version

Certains éditeurs de texte créent des fichiers d’échange temporaires quand vous modifiez un fichier : suffixes .swp, ~, .orig et similaires. Si un développeur modifie un fichier directement sur le serveur, ceux-ci peuvent rester. Ils contiennent souvent le même contenu que le fichier d’origine, mais PHP ne les exécute pas, donc ils sont servis en texte brut si on y accède par URL.

Pire encore, un répertoire .git laissé dans la racine peut exposer tout le dépôt, y compris les commits passés, les branches et les secrets historiques. Cela a été la cause de plusieurs brèches très médiatisées au fil des ans. Le dossier .git ne devrait jamais se trouver sur un serveur en production, ou s’il y est, il doit être bloqué au niveau du serveur.

Comment auditer

L’audit est simple. Connectez-vous en SFTP ou via le gestionnaire de fichiers de votre hébergeur. Parcourez la racine. Tout ce qui se trouve en dehors des fichiers standard du cœur de WordPress à la racine, plus les dossiers wp-admin, wp-includes et wp-content, doit être examiné. Tout ce qui se trouve dans wp-content et qui n’est pas themes, plugins, uploads, mu-plugins ou un dossier de cache connu mérite un examen plus attentif.

Dans le dossier du thème actif, cherchez les sauvegardes datées, les fichiers de test et les restes d’éditeur. Dans le dossier des extensions, cherchez les extensions inactives et envisagez de les supprimer entièrement. Dans uploads, cherchez les fichiers PHP. Il ne devrait presque pas y en avoir.

À quelle fréquence

Un audit mensuel est raisonnable pour un site d’entreprise. Trimestriel est le minimum. Après tout travail de développement ayant impliqué des modifications de fichiers directement sur le serveur en production. Après tout incident, si petit soit-il.

Besoin d’un coup de main ?

Si vous souhaitez faire auditer la racine de votre site WordPress et nettoyer l’encombrement, Defyn peut s’en charger. C’est un travail discret qui fait souvent remonter des problèmes que personne d’autre n’avait remarqués.