WordPress a cette particularité d’être à la fois très simple à administrer et étonnamment facile à laisser exposé à la curiosité du web. Ce n’est pas parce que “c’est WordPress” que c’est automatiquement risqué, mais parce que les usages finissent par diverger du modèle standard. On stocke des fichiers dans des dossiers oubliés. On met en place une arborescence “pratique” pour les clients ou le back-office. On chiffre partiellement, puis on oublie que le navigateur n’a aucune pitié pour les liens directs.
La sécurité qui repose uniquement sur “l’accès est bloqué dans l’interface” est souvent fragile. Le navigateur, lui, sait très bien deviner les chemins. D’où l’intérêt d’un audit ciblé sur deux sujets: les répertoires privés (ce que vous pensez ne pas exposer) et l’accès direct (ce qui peut être récupéré sans passer par WordPress).
Ce texte se concentre sur une approche réaliste, celle qu’on met en place quand on audit un site existant avec un historique, des contraintes d’hébergement et des habitudes d’équipe. L’objectif n’est pas de “tout fermer”, mais de comprendre ce qui est vraiment public, ce qui est réellement restreint, et ce qui l’est “par accident”.
Pourquoi les répertoires privés sont souvent la première zone grise
Sur un WordPress “classique”, beaucoup de chemins sont déjà publics. Les fichiers de thèmes, d’images et parfois même certains scripts le sont. C’est normal. Là où ça se complique, c’est quand on ajoute une couche de rangement: des dossiers pour les PDF, les factures, des exports, des documents d’équipe, des assets pour une application interne, des archives de logs, voire des sauvegardes.
Il y a aussi les pratiques de contournement qui naissent du besoin. Un client veut un lien vers un fichier, mais “pas accessible à tout le monde”. On crée alors un dossier hors de wp-content, ou dans wp-content avec des règles additionnelles. On s’appuie sur un plugin, sur une directive serveur, sur un script PHP, ou sur un “détail” de configuration d’hébergement.
Le risque, c’est que ces protections ne couvrent pas le vrai problème. Par exemple:
- le dossier n’est pas listé, mais les fichiers le sont quand on connaît leur nom l’accès passe par WordPress, mais le fichier est accessible autrement la règle protège le dossier, sauf si l’objet est référencé via un autre emplacement ou un autre virtual host la règle a été écrite pour un serveur précis, puis l’hébergement a changé
Le premier bénéfice d’un audit est simple: arrêter de croire à l’intention (“c’est privé”) et regarder la réalité (“est-ce téléchargeable depuis l’extérieur ?”).
Comprendre la différence entre “privé pour WordPress” et “privé pour le serveur”
Avant même de tester, il faut clarifier ce qu’on veut dire par “privé”.
Un dossier peut être privé “du point de vue de WordPress” parce que WordPress n’y fait pas référence, ou parce que l’URL n’est pas exposée via une route, ou parce que votre logique empêche l’affichage. Mais si le serveur web sait servir le fichier directement, le navigateur peut l’obtenir sans demander à WordPress.
À l’inverse, un dossier peut être “privé du point de vue du serveur”, par exemple grâce à des règles Apache dans .htaccess, à des politiques Nginx, ou à des options d’hébergement qui désactivent l’accès statique. Cette protection est la bonne direction, mais elle dépend de la configuration effective et de la manière dont WordPress est déployé (structure des répertoires, symlinks, reverse proxy, conteneur, etc.).
Dans les audits que j’ai menés, la majorité des surprises viennent de cette confusion. Les équipes ont parfois mis en place une restriction côté application, puis ont ajouté un second chemin côté serveur sans s’en rendre compte. Résultat: une protection “qui marche quand tout passe par WordPress”, et une exposition “quand quelqu’un tente un accès direct”.
Plan de test: partir des hypothèses et les valider comme un attaquant patient
Un audit sérieux n’a pas besoin d’outils exotiques pour commencer. Il faut surtout adopter une méthode de vérification qui ne se contente pas de “ça marche chez moi”.
La démarche la plus productive consiste à lister les répertoires qui contiennent des données potentiellement sensibles ou simplement pas destinées à une distribution publique. Ensuite, il faut tester plusieurs scénarios de récupération:
- accès à l’URL exacte du fichier accès au dossier (listing ou erreur selon le serveur) accès à des variations d’URL (sans extension, avec extension, encodages) accès direct à un fichier via un chemin alternatif (symlink, alias, sous-domaine, cache, CDN) accès depuis l’extérieur du réseau (pas depuis un IP interne protégée)
Le point important est de tester dans la configuration réelle: le site tel qu’un visiteur voit le nom de domaine et les éventuels redirections, sans biais “admin connecté”, sans cookies d’auth WordPress. Ce sont souvent les tests “sans session” qui révèlent les expositions les plus gênantes.
Exemple concret d’un cas fréquent
J’ai vu un dossier “documents” placé sous wp-content/uploads/private-docs/. L’équipe avait mis un plugin qui restreignait l’accès aux documents via une page WordPress protégée par connexion. Tout semblait correct tant qu’on passait par la page.
Mais un téléchargement direct sur l’URL du fichier retournait le contenu. Le plugin ne faisait que contrôler l’interface. Le serveur, lui, servait les fichiers statiques. La preuve était implacable: pas besoin d’exploiter une faille applicative, juste deviner le chemin.
Ce genre d’erreur ne se règle pas en renforçant WordPress. Il se règle en renforçant la couche serveur, et en confirmant que rien d’ordinaire ne donne accès au contenu par un chemin connu.
Où chercher en priorité dans WordPress
WordPress ne cache pas par magie tout ce qui est sensible. Les emplacements “logiques” attirent les mauvais comportements. Voici les zones où un audit me paraît le plus rentable.
- wp-content/uploads: c’est le stockage le plus fréquent, donc aussi le plus exposé. Beaucoup de sites y déposent des PDF, des images, parfois même des documents qui ne devraient pas être publics. wp-content en général: plugins, thèmes, caches, fichiers générés. Si un développeur a pris l’habitude de stocker des exports ici, le risque augmente. les répertoires ajoutés par l’application: des dossiers créés “à côté” du site, souvent avec des noms compréhensibles. Plus le nom est explicite, plus l’attaque par devinette devient simple. les fichiers de sauvegarde et d’archives: même si “ça n’est pas censé être là”, un oubli arrive. Un audit doit vérifier qu’ils ne sont pas accessibles via HTTP. les chemins mappés par l’hébergement: certains hébergeurs mettent des liens symboliques, des mappings ou des règles CDN. L’URL peut pointer vers un emplacement différent de celui que vous pensez.
L’idée n’est pas de tout bloquer. Certains fichiers doivent être servis. Mais si un contenu est censé rester privé, il doit l’être au niveau du serveur, pas uniquement au niveau de l’interface WordPress.
Tester l’accès direct: ce que vous devez vérifier, sans vous tromper de cible
Un point qui revient souvent: on vérifie “depuis l’espace admin”, puis on conclut. C’est utile pour diagnostiquer des permissions WordPress, mais ce n’est pas une preuve d’accès direct. Les protections “admin” passent par des sessions et des contrôles applicatifs. Or votre sujet ici, ce sont les requêtes directes.
Je recommande d’observer trois aspects.
D’abord, le comportement du serveur sur les dossiers privés. Un accès à un dossier peut retourner une erreur 403, une redirection, ou parfois une page d’erreur qui révèle trop (par exemple le serveur ou la structure). Si c’est accessible, même partiellement, le risque existe. Une erreur “404” peut sembler “safe”, mais elle peut aussi signifier “ça existe mais je le masque”. Le bon objectif est d’éviter la divulgation du contenu, et idéalement de contrôler la réponse sans fuite.
Ensuite, le comportement sur les fichiers individuels. Un dossier peut être bloqué, mais les fichiers peuvent être récupérés si les règles ne couvrent pas correctement toutes les extensions. Sur Apache, une règle mal placée dans .htaccess peut protéger un type de fichier et en exposer un autre. Sur Nginx, un location incomplet peut laisser un chemin servir un contenu statique.
Enfin, le comportement quand un CDN ou un cache intervient. Si vous utilisez un CDN, une règle que vous corrigez peut ne pas s’appliquer immédiatement partout. Pire, un cache peut servir une réponse déjà stockée. L’audit doit idéalement confirmer sur le chemin réel, après purge, ou en contournant le cache si votre infrastructure le permet.
.htaccess, règles serveur, et leurs angles morts
Beaucoup de sites WordPress utilisent Apache, ou une couche Apache derrière un reverse proxy. Dans ce contexte, .htaccess reste un outil courant. Mais .htaccess a aussi des limites: il dépend de AllowOverride, de la racine effective, et de l’interaction avec la configuration globale.
Un angle mort classique: une règle est écrite dans le .htaccess de WordPress, mais le dossier concerné n’est pas inclus dans le même contexte. Résultat, la règle ne s’applique pas, ou s’applique seulement dans certaines situations. Autre cas: un dossier est bloqué, mais des sous-dossiers ou des extensions échappent à la règle. Le “privé” devient relatif, par oubli.
Sur Nginx, la logique est plus “explicite” via des blocs location, ce qui aide à raisonner, mais exige une bonne cartographie des chemins. Si WordPress est servi depuis un root différent, ou si un alias pointe vers un autre répertoire, la règle doit suivre la réalité de ce mapping.
Dans tous les cas, ce qui compte en audit, c’est de valider empiriquement. La théorie des règles est utile, mais seule la requête réelle confirme.
Vérifier les extensions, les formats et le “bête” accès aux fichiers
Quand on parle d’accès direct, on imagine souvent “des fichiers sensibles”. En pratique, les expositions prennent des formes variées:
- PDF ou ZIP dans un dossier “uploads” mais pas destinés à tous exports CSV contenant des données images générées à la volée qui contiennent des identifiants ou des détails sensibles documents bureautiques avec des métadonnées scripts ou archives laissés par une maintenance
Un détail que j’ai appris à respecter: beaucoup de règles de blocage sont écrites en pensant à un type de contenu. Si vous bloquez uniquement .pdf, mais que vous avez aussi .zip, le risque reste entier. À l’inverse, si vous bloquez trop large, vous cassez des fonctionnalités légitimes. D’où la nécessité d’un audit par type de fichier, au moins à minima, en fonction de ce que votre site stocke réellement.
Un bon test consiste à prendre quelques fichiers représentatifs du contenu privé, pas des “fichiers vides”. Vérifiez aussi les fichiers “moins attendus” comme les .json ou les .txt si vous en produisez.
Sécuriser sans casser: arbitrer entre confidentialité et accessibilité
Bloquer “tout ce qui n’est pas public” semble simple sur le papier, mais sur un site vivant, les compromis sont inévitables.
Par exemple, vous pouvez décider de déplacer les documents privés hors de wp-content. C’est une approche saine, mais elle oblige à adapter votre application. Si vous comptez sur WordPress pour livrer ces fichiers, il faudra une logique de streaming contrôlé, des en-têtes adaptés, et une gestion des permissions.
Autre compromis fréquent: utiliser une authentification serveur ou un contrôle d’accès HTTP. Cela peut réduire l’effort applicatif, mais peut aussi perturber certains clients (bots de monitoring, intégrations, téléchargeurs automatiques). Et surtout, les utilisateurs finaux ne reçoivent pas forcément une page confortable.
La bonne approche consiste souvent à choisir un “mode de distribution” clair:
- soit le contenu privé n’est jamais servi par HTTP direct, seulement via un contrôleur applicatif qui vérifie la session soit il est servi directement, mais la couche serveur impose une authentification et protège aussi la découverte soit il est servi via des liens temporaires, mais cela demande un design réfléchi (expiration, rotation, protection contre la réutilisation)
L’audit des répertoires privés sert justement à décider quel modèle est approprié. Si vous découvrez que le site a des dizaines de fichiers privés dans des chemins variés, “ajouter une règle au cas par cas” devient fragile. À un moment, il faut rationaliser.
Procédure pratique d’audit: une base solide sur laquelle itérer
Voici une méthode simple, sans magie, que j’utilise comme trame lors de missions d’audit et de remédiation progressive.
- Identifier tous les répertoires contenant du contenu non destiné au grand public, en incluant les dossiers ajoutés par l’équipe ou par des plugins. Lister 3 à 10 fichiers “représentatifs” et sensibles dans chaque dossier, y compris des archives et des formats inattendus. Tester depuis une session non connectée, et aussi depuis un utilisateur sans droits sur WordPress, les URLs directes des fichiers et l’accès au dossier. Vérifier le comportement exact du serveur (codes HTTP, présence de listing, contenu réellement retourné, headers qui pourraient révéler). Tester après corrections, en purgeant cache/CDN si présent, pour éviter les faux positifs dus à une réponse en mémoire.
Cette approche limite le risque de se faire piéger par une protection partielle ou par un cache.
Signes d’alertes qui reviennent dans les audits
On ne doit pas attendre un incident pour agir. Certains symptômes sont suffisamment répétitifs pour servir de boussole.
1) Des fichiers “correctement nommés” restent accessibles à partir d’une URL simple. Quand le chemin ressemble à un dossier, et que les noms sont explicites, l’accès direct est souvent à portée de navigateur.
2) Un blocage qui marche uniquement pour une page WordPress, mais pas pour les fichiers. C’est un signe que la restriction est applicative, pas serveur.
3) Des redirections incohérentes entre http et https, entre domaine et sous-domaine. J’ai vu des protections appliquées sur un host, puis un autre host servait le contenu.
4) Un “tout marche” pendant l’audit interne, puis une exposition dès qu’on teste depuis l’extérieur. Cela pointe vers des restrictions IP, des règles qui ne s’appliquent qu’à un réseau, ou une politique de pare-feu oubliée.
5) Des dossiers privés qui contiennent des fichiers de maintenance, comme des exports automatiques ou des archives générées par des tâches cron.
Ces signes ne prouvent pas la vulnérabilité, mais ils indiquent où concentrer l’effort, pour passer de la suspicion à la preuve.
Edge cases: ce qui casse les protections les plus “logiques”
Dans la vraie vie, certaines situations font que même une bonne intention de configuration ne suffit pas.
Symlinks et répertoires “réels” différents
Sur certains hébergements, des liens symboliques relient des chemins. Un .htaccess écrit sur le chemin apparent peut ne pas couvrir le répertoire cible si la configuration ne suit pas. Vous croyez protéger un dossier, mais vous protégez un alias.
Le test direct montre le problème, mais en remédiation, il faut aussi comprendre où le fichier est réellement stocké.
Alias Nginx ou configurations de virtual host
Si votre site est derrière un reverse proxy, ou si plusieurs virtual hosts existent, les règles peuvent être appliquées à un host et pas à un autre. Résultat: même URL apparente, mais réponse différente selon le domaine. L’audit doit inclure au moins les variantes de domaine utilisées en production.
CDN et expiration de règles
Une correction serveur peut être efficace, puis redevenir floue côté utilisateur pendant un laps de temps à cause du cache. L’audit doit donc intégrer une vérification post-modification, idéalement après purge, ou en utilisant un test qui contourne le cache si possible.
Compression, transformations et “fichiers dérivés”
Un dossier privé peut contenir des fichiers, mais aussi des fichiers dérivés générés par WordPress, ou par une pipeline (images converties, minifications, variantes). Si la génération produit une copie dans un chemin public, vous exposez le contenu même si le dossier source est protégé.
C’est particulièrement visible quand on manipule des médias, ou quand un plugin de conversion crée des formats supplémentaires.
Remédiation: choisir une stratégie cohérente selon votre contexte
Une correction efficace dépend de votre paysage technique. Je vois trois stratégies qui fonctionnent, chacune avec ses avantages et ses limites.
Première stratégie: déplacer le stockage privé hors des répertoires servis directement par le serveur web. Ensuite, livrer via une route applicative qui vérifie les permissions. C’est robuste sur l’exposition, car il n’y a plus de chemin statique simple vers les fichiers. Le coût, c’est un effort de développement ou de configuration, et parfois des contraintes de performance si vous servez beaucoup de gros fichiers.
Deuxième stratégie: garder le stockage au bon endroit, mais durcir la couche serveur pour bloquer l’accès statique. Ensuite, vous vous appuyez sur des mécanismes d’authentification ou de contrôle d’accès. C’est souvent plus simple quand vous voulez éviter de construire une logique applicative de streaming. Mais il faut être minutieux, vérifier toutes les extensions, et confirmer les interactions avec CDNs et proxies.
Troisième stratégie: liens temporaires et contrôle d’accès par signature. Le principe est de générer des URL valides un temps limité, de sorte que même si une URL fuite, elle ne reste pas utilisable. Cette stratégie est exigeante, car elle demande une gestion correcte de l’expiration, une rotation des secrets et un design contre la réutilisation. En audit, elle doit être évaluée avec attention, car une implémentation partielle peut donner un faux sentiment de sécurité.
Quel que soit votre choix, l’audit doit se conclure par une validation réelle. Pas par une relecture de règles, mais par des tests d’accès direct sur des fichiers concrets.
Contrôler durablement: éviter que la protection “revienne à zéro” avec le temps
La sécurité n’est pas un sprint, c’est un mécanisme de maintien. Sur WordPress, les changements sont fréquents: mise à jour de plugins, migration d’hébergement, ajout de chemins par un nouveau composant. À chaque fois, la cartographie des protections peut être affectée.
Sans transformer votre maintenance en usine à gaz, vous pouvez instaurer une routine légère d’audit. Une bonne pratique que j’ai vue fonctionner est de conserver une mini “banque de tests”: quelques URLs de fichiers réellement https://gardewp.fr/securite-wordpress/ sensibles (ou au moins représentatifs) que vous testez après toute modification majeure. Cela réduit les erreurs de régression.
L’autre point durable, c’est la gouvernance interne. Beaucoup d’expositions viennent d’un nouveau besoin qui s’est greffé sans repenser l’architecture. Un dossier “temporaire” ajouté par un plugin peut devenir permanent. Un export “juste une fois” finit dans uploads. Si vous mettez en place un guide interne sur où stocker et comment protéger les contenus non publics, vous diminuez la probabilité que le problème revienne.
Focus: documents privés dans uploads, le cas le plus fréquent
Si vous gérez des documents privés, vous allez probablement tomber sur wp-content/uploads. C’est le piège le plus banal: c’est pratique, tout le monde y met tout, et ensuite on tente de corriger.
Dans ce cas, je privilégie une approche en deux étapes. D’abord, catégoriser: quels fichiers doivent rester publics, lesquels doivent être réservés, et lesquels doivent être complètement dissimulés. Ensuite, choisir un modèle.
Souvent, la meilleure solution n’est pas de “bloquer uploads” dans son ensemble, ce qui casserait la distribution d’images. La solution consiste plutôt à isoler une sous-partie clairement destinée au privé, et à traiter ce sous-espace de manière stricte, que ce soit par règles serveur ciblées ou par livraison via WordPress contrôlée.
C’est là que l’audit des répertoires privés prend toute sa valeur: il vous dit précisément où se situe la “sous-partie privée”, et si elle est effectivement privée contre l’accès direct.
Conclusion opérationnelle: ce que signifie vraiment “sécuriser”
Sécuriser WordPress sur la question des répertoires privés et de l’accès direct revient à une idée simple: empêcher la récupération non autorisée, pas seulement empêcher l’affichage via l’interface.
Un audit utile vous donne des preuves. Vous savez alors, pour chaque dossier concerné, si le serveur sert réellement le contenu, si la protection s’applique à toutes les extensions, si le CDN ou le cache brouille les corrections, et si les règles survivent aux changements d’infrastructure.
Si vous devez retenir un seul réflexe, c’est celui-ci: testez l’accès direct comme si vous n’aviez aucun compte, aucun cookie, et aucune relation avec le site. Votre but n’est pas d’anticiper une faille exotique, c’est de vérifier qu’un chemin simple ne suffit pas à exfiltrer vos documents.
Si vous voulez, je peux aussi proposer une grille d’audit adaptée à votre configuration (Apache ou Nginx, présence de CDN, structure de dossiers, types de fichiers concernés). Donnez simplement le plan de vos chemins privés et le comportement actuel observé (codes HTTP, messages de serveur, éventuelles redirections).