Quand on parle de protection WordPress, on pense souvent à la force brute, aux plugins “sécurité”, ou à la fermeture d’un port. Tout cela compte, mais il y a un angle plus discret et, parfois, plus rentable: vérifier ce que WordPress (et surtout votre serveur) laisse fuiter comme chemins, fichiers et points d’accès. Un attaquant n’a pas besoin de tout casser s’il peut d’abord comprendre où chercher.
Dans la pratique, la majorité des expositions viennent de trois endroits. D’abord, la configuration du serveur web (Nginx, Apache), les règles de cache, les alias et les répertoires. Ensuite, la configuration WordPress elle-même, notamment les erreurs, la journalisation, les chemins de fichiers, et certains vieux plugins. Enfin, ce qui est “techniquement public” sans être “fonctionnellement utile”, comme des fichiers de backup, des index de répertoires, ou des restes de déploiements.
Ce qui suit décrit une démarche réaliste pour repérer les chemins et fichiers exposés, comprendre ce que cela implique, puis corriger sans casser votre site.
Ce que signifie “chemins et fichiers exposés”
Un “chemin exposé”, ce n’est pas uniquement un fichier que l’on peut télécharger. C’est aussi une information qui rend l’attaque plus efficace: structure des répertoires, noms de dossiers, présence de fichiers de configuration, arborescence de thèmes et plugins, traces dans des réponses HTTP, et erreurs qui révèlent trop de détails.
Exemples concrets que j’ai vus sur des environnements WordPress:
- Une page 404 qui affiche un chemin de serveur, ou une erreur PHP qui cite le fichier exact (avec répertoires système et noms internes). Un répertoire temporaire ou de cache qui liste ses contenus (même si ce n’est pas censé être indexé). Des fichiers générés par des outils de déploiement (ancien dump, archive, sauvegarde) qui finissent dans le webroot. Des fichiers “log” ou “debug” accessibles au navigateur. Des URLs “bizarres mais prévisibles” (le genre de choses qu’un bot teste sans réfléchir) qui renvoient des réponses différentes selon l’existence réelle.
L’enjeu n’est pas de transformer votre site en coffre-fort absolu. L’enjeu est de réduire la surface utile, et surtout d’éviter que des informations internes deviennent une feuille de route.
Comprendre d’abord votre surface: WordPress, mais aussi le serveur
Avant de courir après des URLs, prenez deux minutes pour clarifier ce qui vous parle réellement.
WordPress vit dans un sous-ensemble d’un écosystème plus large: PHP, le runtime, le système de fichiers, et le reverse proxy éventuel. Même si WordPress est “bien configuré”, un serveur mal réglé peut exposer des répertoires ou laisser des fichiers statiques accessibles.
Sur un projet récent, on croyait que le risque venait du CMS. En réalité, les permissions et la configuration d’indexation côté serveur permettaient d’afficher un répertoire “uploads” dans certains cas. WordPress affichait bien ses pages, mais des chemins annexes renvoyaient des listings. Résultat: un attaquant pouvait cartographier en quelques minutes ce qui avait été mis en ligne, y compris des fichiers non destinés au public. La correction n’a pas été un changement WordPress, mais une remise en état du comportement du serveur.
Gardez donc en tête que “chemins exposés” renvoie à deux familles: 1) ce que WordPress montre dans ses réponses, 2) ce que votre webserver laisse respirer au niveau fichiers et répertoires.
Observer les réponses HTTP: le premier détecteur d’exposition
La première étape, c’est d’observer. Pas de “scans au hasard”, mais des observations ciblées.
Commencez par vérifier les réponses HTTP de pages qui devraient être standard, puis comparez avec des endpoints moins https://gardewp.fr/securite-wordpress/ évidents. Un motif récurrent: quand un fichier existe, le serveur renvoie un type de réponse différent (code HTTP, taille, en-têtes). Quand il n’existe pas, la réponse “tombe” dans le mécanisme 404 ou renvoie une page WordPress.
Ce contraste aide à distinguer:
- un fichier réellement présent, un alias de répertoire, une règle de redirection, une logique d’erreur qui divulgue trop.
Sans entrer dans une méthode “magique”, ce que je fais généralement, c’est:
- tester plusieurs URL candidates qui devraient être inaccessibles, regarder les codes HTTP, les en-têtes (Content-Type, Server, X-Powered-By si présent), et surtout observer les messages d’erreur et les détails de réponse.
Un exemple classique: si PHP affiche une erreur complète, on peut voir le chemin de fichier, la ligne problématique, et parfois le nom de classe ou le plugin. Ce n’est pas uniquement un risque de fuite d’information, c’est aussi une aide à l’exploitation (l’attaquant peut cibler le bon point).
Vérifier la configuration PHP: erreurs, logs et affichage
Beaucoup d’expositions “chemins et fichiers” passent par l’affichage des erreurs. WordPress peut fonctionner avec les erreurs PHP désactivées en production, mais une configuration par défaut ou une variable d’environnement peut réactiver l’affichage.
Vous cherchez deux comportements:
- un navigateur qui reçoit des messages PHP détaillés, un site qui renvoie des traces dans ses pages, même via un 404 ou une requête inattendue.
Sur certains hébergements, j’ai vu “display_errors” activé par héritage, uniquement sur un sous-domaine, ou uniquement sur un environnement de staging. Une erreur qui ne se produit que pour certaines conditions devient un outil de reconnaissance.
Concrètement, assurez-vous que l’environnement de production n’affiche pas les erreurs PHP au client. Les erreurs doivent aller dans des logs serveurs, que l’on consulte de façon interne. Le compromis est simple: vous perdez un peu de confort de diagnostic “dans la page”, mais vous gagnez en contrôle. Et en production, on a besoin d’une procédure de debug propre, pas de messages bruyants.
Le chapitre souvent oublié: indexation et listes de répertoires
Même quand vous “cachez” WordPress, un serveur peut exposer un répertoire via listing. Les bots testent cela systématiquement, et les erreurs de configuration sont relativement fréquentes.
Deux cas reviennent:
- les répertoires qui n’ont pas de fichier index, donc le serveur affiche une liste, les chemins “dynamiques” qui miment des répertoires (ex: dossiers temporaires, caches, exécutions).
Votre objectif n’est pas d’empêcher toute réponse listée à tout prix, c’est de s’assurer que les répertoires sensibles ne soient jamais indexables et jamais listables publiquement.
Dans les corrections que j’ai menées, le plus efficace a souvent été:
- interdire l’affichage des index de répertoires, vérifier les règles pour les dossiers de cache et de compilation, et s’assurer que les dossiers WordPress standards ne donnent pas de listing.
Le revers de la médaille: si vous utilisez des mécanismes particuliers (CDN, cache dynamique, optimisation de performance), certaines règles peuvent influencer la génération de fichiers. Il faut tester après modification.
Les fichiers “évidemment sensibles” que les scanners recherchent
Les scanners et les attaquants suivent des patterns. Cela ne veut pas dire qu’ils ont raison à 100 pour cent, mais que les fichiers sont suffisamment “connus” pour que la recherche automatisée fasse le travail.
Vous pouvez considérer la protection comme une réduction des probabilités qu’un bot tombe sur un fichier exploitable.
Sans tomber dans une liste interminable, je pense à des catégories de fichiers qui posent problème quand ils sont exposés:
- fichiers de configuration et de sauvegarde (y compris des archives générées lors de migrations), fichiers de logs contenant des requêtes, des jetons, des erreurs détaillées, des backups oubliés, parfois créés par des outils de maintenance, des fichiers de traces d’un environnement de staging, des artefacts de déploiement (anciennes versions, packages, dumps).
Le point pratique est que ces fichiers ne “deviennent pas” dangereux en soi. Ils deviennent dangereux quand ils sont à la fois accessibles publiquement et suffisamment détaillés pour guider une exploitation.
Rechercher les “restes de déploiement” dans vos chemins
Le cas le plus douloureux n’est pas le fichier ultra-sensible. C’est l’archive moyenne, déposée une semaine trop tôt, jamais retirée, et accessible depuis le web.
J’ai déjà vu des environnements où une archive de migration était restée dans un dossier temporaire qui finissait par être servi par le serveur web. En apparence, rien n’indiquait que c’était un problème, car l’archive n’était pas “dans la racine”. Mais les règles de serveur, les alias, et la façon dont certaines plateformes montent des volumes peuvent rendre ce qui semblait “hors web” accessible.
C’est là que la vérification des chemins et fichiers exposés prend son sens. Votre contrôle doit inclure:
- la racine du site, les répertoires “classiques” comme uploads, mais aussi les dossiers qui accompagnent le cycle de vie (staging, maintenance, déploiements, caches).
Un moyen simple de s’auto-auditer: comparez la liste des fichiers réellement présents sur le serveur à la liste de ce qui devrait y être. Toute archive, tout zip, tout tar, tout dump, tout fichier de debug ajouté pendant une maintenance mérite un traitement: soit supprimer, soit verrouiller, soit déplacer hors webroot.
Vérifier ce que WordPress révèle à travers les erreurs et la configuration
WordPress n’est pas un mauvais élève par défaut, mais il peut révéler trop d’informations si certaines options sont activées, notamment liées au debug.
Le symptôme est concret: des pages qui “donnent des détails” quand on provoque une erreur. Par exemple, une requête vers un endpoint inexistant ne devrait pas faire apparaître un stack trace ou un chemin complet vers un fichier.
Dans beaucoup d’environnements, l’idée est de faire en sorte que:
- les erreurs fatales ne s’affichent pas dans le navigateur, les logs internes restent consultables par l’équipe, et le site réponde avec des pages d’erreur sobres et cohérentes.
Le trade-off, c’est le debug. Si vous désactivez trop tôt l’affichage des erreurs en pleine phase de correction, vous pouvez perdre du temps. Sur un projet, on a résolu ça en gardant les erreurs masquées en production, mais en activant temporairement un mécanisme contrôlé sur une fenêtre courte, uniquement pour une IP de l’équipe. Cela réduit les fuites, tout en gardant un diagnostic rapide.
Contrôle des plugins et thèmes: ne pas confondre “exposition” et “fonctionnalité”
Beaucoup de gens regardent uniquement les fichiers WordPress core. C’est insuffisant.
Les plugins ajoutent leurs propres répertoires, leurs endpoints, et parfois leurs fichiers de données. Certains plugins exposent des fichiers de manière non intentionnelle, ou laissent des accès à des scripts de maintenance. D’autres créent des répertoires temporaires dans des zones qui finissent servies.
Par ailleurs, des thèmes peuvent inclure des assets ou des fichiers auxiliaires (par exemple des exports, des fichiers de traduction au format particulier, ou des scripts de dev). Dans des cas extrêmes, j’ai vu des fichiers “.log” ou des “.txt” rester dans un chemin exposé.
La vérification des chemins et fichiers exposés doit donc inclure votre inventaire réel de plugins et thèmes. Si un plugin n’est plus utilisé, le meilleur correctif n’est pas de patcher à l’infini, c’est de désinstaller proprement et de vérifier qu’il ne laisse pas des artefacts en face.
Une procédure d’audit raisonnable, sans tomber dans le bruit
Vous pouvez faire un audit de manière structurée. L’idée n’est pas de scanner toute la toile, c’est de contrôler votre propre logique d’exposition.
Voici comment je procède, étape par étape, sur un site WordPress en production:
- vérifier les erreurs côté navigateur en déclenchant volontairement des routes inexistantes, et en surveillant si des chemins systèmes apparaissent, observer les réponses à des requêtes “non fonctionnelles” mais prévisibles (codes HTTP, types de contenu, variations), contrôler les répertoires susceptibles d’être listables et les caches ou dossiers temporaires, comparer les fichiers attendus dans les répertoires web à ceux réellement présents.
Ces étapes doivent être répétées après chaque changement serveur ou après une mise à jour majeure, parce qu’une modification de configuration peut réintroduire une exposition.
Il y a une nuance importante: tout n’est pas corrigible sans effet de bord. Par exemple, une configuration qui bloque certains types de fichiers peut casser un usage légitime, comme un export de document via uploads, ou une configuration d’intégration qui attend un fichier statique bien précis. Il faut ajuster au cas par cas.
Corriger sans casser: verrouiller les chemins et réduire la divulgation
Une bonne correction commence par une règle claire: “le client ne doit pas voir ce qu’il n’a pas besoin de voir”.
Cela passe généralement par:
- la désactivation de l’affichage des erreurs côté client, l’interdiction de listing des répertoires, la restriction d’accès aux fichiers non destinés au web, et la suppression ou le déplacement des archives et fichiers temporaires.
Le danger, c’est la surcorrection. J’ai déjà vu des équipes bloquer trop large, par exemple en interdisant certains types de fichiers dans uploads, puis en découvrant après coup que des documents utilisés par les équipes (PDF, CSV, ZIP de ressources) ne se téléchargeaient plus correctement. Pour éviter ça, la correction doit être guidée par l’usage réel.
Un autre piège: les systèmes de cache et CDN. Si vous bloquez des endpoints ou modifiez les règles d’accès, le CDN peut mémoriser des réponses inattendues. Résultat, vous croyez que “c’est corrigé” alors que le cache sert encore l’ancien comportement. Testez avec un cache vidé ou en mode neutral, et observez les en-têtes.
Cas limites: quand l’exposition n’est pas un bug, mais un design
Parfois, un chemin “visible” n’est pas un risque en soi. Par exemple, la structure de l’URL des médias WordPress (uploads avec année et mois) est un standard. Le fait que le serveur renvoie le bon chemin pour un fichier existant ne signifie pas qu’un fichier sensible est accessible.
Le vrai signal de danger, c’est quand vous découvrez:
- un fichier qui ne devrait pas exister à cet endroit, ou un comportement qui révèle des chemins internes, ou une différence de réponse qui indique la présence de quelque chose d’inaccessible normalement.
En clair, on protège la logique d’accès et la divulgation d’informations, pas la simple existence d’une URL.
Ce que j’aurais aimé vérifier plus tôt sur mes projets
Sur plusieurs audits, les retours “humains” reviennent souvent: le plus gros gain vient rarement d’une seule correction spectaculaire. Il vient d’un enchaînement de petites décisions.
On retire un zip oublié. On corrige le listing. On masque les erreurs PHP. On désactive le debug. On verrouille un dossier de cache. On supprime un fichier de logs accessible. Chaque point semble petit, mais ensemble, ils réduisent fortement la cartographie utile pour un attaquant.
Et c’est là que la protection WordPress devient vraiment pragmatique: ce n’est pas “avoir des outils”. C’est savoir ce qui est exposé, pourquoi, et comment le corriger avec méthode.
Mini check interne avant et après correction
Si vous voulez un repère simple pour cadrer votre travail, retenez ce principe: après toute modification, vérifiez à nouveau la même série de scénarios. Les expositions réapparaissent souvent via des changements “qui semblaient innocents”, comme une mise à jour du serveur web, un changement de reverse proxy, ou un nouveau plugin de performance.
Voici un dernier point de contrôle, rapide et ciblé:
- vos erreurs 404 et erreurs PHP ne révèlent pas de chemins système, les répertoires sensibles ne sont pas listables, les fichiers de backup et d’artefacts de déploiement ne sont pas accessibles via le web, votre site reste fonctionnel pour vos usages documentés (uploads, téléchargements, médias).
Si vous ne faites que trois corrections, faites celles-ci en premier. Elles donnent un bon ratio effort et effet, et elles réduisent à la fois la surface d’attaque et la divulgation d’informations.
Garder la protection dans la durée
Une protection WordPress “vivante” ne se limite pas à un audit unique. WordPress évolue, les plugins changent, les environnements passent en staging puis repassent en production, et les règles serveur peuvent être retouchées par quelqu’un d’autre.
Concrètement, je recommande de traiter la vérification des chemins et fichiers exposés comme un contrôle récurrent, pas comme une chasse au trésor ponctuelle. Après chaque déploiement, vérifiez ce qui change le plus facilement: comportement des erreurs, listing de répertoires, et présence d’artefacts de maintenance dans des dossiers exposés.
Si vous voulez gagner du temps, la meilleure stratégie reste la discipline: nettoyer les fichiers temporaires, documenter les emplacements “utiles”, et exiger que tout déploiement propre supprime ses traces côté web.
En matière de sécurité, ce sont souvent les détails ordinaires qui font la différence. Et quand l’équipe sait quoi regarder, l’audit n’est plus une aventure technique, c’est une routine efficace.