Le malentendu de départ
Beaucoup de dirigeants croient qu'un fichier n'est accessible que s'il existe un lien vers lui. C'est faux, et c'est le malentendu qui coûte le plus cher en matière d'exposition. Un serveur web sert tout ce qui se trouve dans son dossier public, à qui demande la bonne adresse. Le lien sert à trouver la page ; il ne protège rien.
Deuxième malentendu : « personne ne devinera ce nom de fichier ». Personne ne devine, en effet. Les robots ne devinent pas, ils parcourent des listes. Ces listes sont publiques, maintenues, et contiennent les quelques centaines de noms que les humains utilisent réellement : backup.zip, site.sql, config.old, .env, wp-config.php.bak. Un site neuf reçoit ce genre de sondage dans les heures qui suivent sa mise en ligne.
Les catégories qui reviennent, par ordre de gravité
1. Les fichiers de configuration. Ils contiennent les identifiants de la base de données, et souvent des clés d'API. Le cas classique n'est pas le fichier lui-même, que le serveur sait généralement protéger, mais sa copie renommée : .env.bak, config.php.old, wp-config.php.save. L'extension a changé, donc la règle de protection ne s'applique plus, et le serveur le sert en texte brut.
2. Les sauvegardes et exports de base. Un .sql ou un .zip laissé après une migration contient l'intégralité du site, comptes et mots de passe chiffrés compris. C'est la trouvaille la plus rentable pour un attaquant, et la plus fréquente après une refonte.
3. Le dossier .git. Déployer un site en copiant un dossier de travail embarque son historique complet. Un dossier .git accessible permet de reconstituer tout le code source, y compris les fichiers supprimés et les identifiants qui y figuraient avant d'être retirés.
4. Les journaux et les fichiers d'erreur. Ils révèlent les chemins absolus du serveur, les versions logicielles et parfois des données de visiteurs.
5. Le listing de répertoire. Ce n'est pas un fichier mais un réglage : quand un dossier n'a pas de page d'index, le serveur affiche la liste de son contenu. L'attaquant n'a alors plus rien à deviner, on lui donne le sommaire.
Le piège du robots.txt
Un réflexe fréquent consiste à écrire dans le robots.txt une ligne du type Disallow: /admin-prive/ pour que Google n'indexe pas la zone. L'intention est bonne, l'effet est l'inverse de celui recherché.
Le robots.txt est un fichier public, lisible par tout le monde à l'adresse votredomaine.fr/robots.txt. Y écrire le chemin d'une zone sensible revient à publier l'adresse de sa porte de derrière. Les robots honnêtes obéissent et n'y vont pas ; les autres y trouvent leur feuille de route, et c'est justement ceux-là qui vous intéressaient.
La règle : le robots.txt sert à orienter l'indexation d'un contenu public. Une zone qui doit rester privée se protège par un mot de passe ou un filtrage d'adresses IP, jamais par une ligne dans un fichier public.
Vérifier le vôtre, sans outil
Ouvrez un onglet et tapez, une par une, ces adresses à la suite de votre nom de domaine. Vous devez obtenir une erreur 404 à chaque fois :
/.envet/.env.bak/backup.zip,/backup.sql,/dump.sql/.git/config/wp-config.php.baksi vous êtes sur WordPress/uploads/ou/files/, pour voir si la liste du dossier s'affiche
Tout ce qui répond autre chose qu'une erreur est à retirer du serveur aujourd'hui, pas à renommer. Renommer déplace le problème : le nouveau nom finira aussi dans une liste. Et si un de ces fichiers a été exposé, considérez que les identifiants qu'il contenait sont compromis : changez-les plutôt que d'espérer que personne n'a regardé.
Le cas particulier des sauvegardes automatiques
Il y a un piège que les vérifications manuelles ratent presque toujours, parce qu'il ne vient pas d'un oubli humain : les extensions de sauvegarde.
La plupart des solutions de sauvegarde pour sites autohébergés écrivent leurs archives dans un sous-dossier du site lui-même, par exemple /wp-content/backups/. C'est pratique et c'est logique du point de vue de l'extension. Le problème est que ce dossier est dans l'arborescence publique : chaque sauvegarde nocturne dépose une archive complète du site, accessible à qui connaît le chemin, et ces chemins sont documentés puisque l'extension est publique.
Le symptôme est traître : vous n'avez rien fait de mal, vous avez au contraire suivi le bon conseil de sauvegarder, et vous avez créé une exposition quotidienne qui se renouvelle toute seule.
Trois corrections, par ordre de solidité :
- Sortir les sauvegardes du dossier public. La plupart des extensions permettent de choisir une destination distante, chez un fournisseur de stockage ou par transfert de fichiers. C'est la bonne réponse, et elle règle aussi le cas où le serveur brûle avec ses sauvegardes.
- Interdire l'accès au dossier par une règle de configuration du serveur, si les sauvegardes doivent rester locales.
- Vérifier après chaque changement d'hébergement, parce qu'une migration remet souvent les réglages du serveur à zéro sans toucher au contenu.
Ce que notre audit mesure
La catégorie exposition et fichiers sensibles compte 8 vérifications. Elle teste une série de chemins réputés sensibles, cherche si le listing de répertoire est actif, si une balise generator annonce votre version logicielle, si des chemins d'administration ou de déploiement répondent, si une bibliothèque JavaScript abandonnée est chargée, si votre robots.txt nomme des chemins d'administration, et si des messages d'erreur techniques s'affichent dans les pages testées.
La limite est nette et assumée : nous testons une liste finie de chemins courants. Un fichier au nom inhabituel, laissé dans un sous-dossier que rien ne lie, ne sera pas trouvé par notre audit. Il ne sera pas trouvé non plus par la plupart des robots, mais l'absence de constat n'est pas une preuve d'absence de fichier. La seule vérification exhaustive reste la liste du contenu réel de votre dossier public.