Chemins sensibles exposés : .env, .git, /admin — comment les détecter et les bloquer

Une fuite silencieuse et dévastatrice

Imaginez qu'un attaquant puisse accéder à https://votresite.fr/.env et y lire vos clés API, vos identifiants de base de données et vos secrets de chiffrement. C'est exactement ce qui se passe sur des milliers de sites chaque jour.

Ces expositions ne sont généralement pas causées par des bugs complexes, mais par de simples erreurs de configuration ou de déploiement.

Les fichiers et chemins les plus dangereux

Fichiers de configuration : /.env /.env.local /.env.production /config.php /wp-config.php /database.yml

Fichiers de version : /.git/config /.git/HEAD /.svn/entries

Interfaces d'administration : /admin /phpmyadmin /wp-admin /manager (Tomcat) /console

Fichiers de sauvegarde : /backup.zip /db.sql /site.tar.gz

Comment ces expositions se produisent

La cause la plus fréquente est un déploiement direct depuis un dépôt Git. Si le répertoire .git est inclus dans les fichiers déployés et que le serveur ne bloque pas l'accès, n'importe qui peut reconstruire le code source et accéder aux configurations.

Une autre cause courante : les fichiers .env qui ne sont pas exclus du dossier public par la configuration du serveur web.

Comment bloquer ces accès avec nginx

location ~ /\. {
  deny all;
  return 404;
}

location ~* \.(env|git|sql|bak|zip|tar)$ {
  deny all;
  return 404;
}

Comment bloquer avec Apache (.htaccess)

<FilesMatch "^\.env|\.git|\.sql|backup">
  Require all denied
</FilesMatch>

La détection automatique

WebImpulsion teste automatiquement plus de 30 chemins sensibles courants lors de chaque audit. Si un chemin répond avec un code 200 (accessible) alors qu'il devrait retourner 404 ou 403, vous en êtes informé avec le niveau de criticité correspondant.

C'est une vérification que vous devriez faire régulièrement, car un déploiement peut accidentellement réexposer un fichier qui était correctement bloqué.