Empêcher l’exposition de .env, .git et fichiers de sauvegarde
C'est l'une des fuites les plus graves et, paradoxalement, les plus banales : un fichier .env contenant vos mots de passe de base de données, un dossier .git exposant tout votre code source, ou une sauvegarde backup.zip laissée à la racine après une intervention. Aucun piratage sophistiqué ici — ces fichiers sont accessibles d'un simple GET, comme n'importe quelle page.
Et ils ne passent pas inaperçus : des robots malveillants balaient en permanence le web en testant une liste connue de noms de fichiers sensibles (.env, .git/config, backup.zip, dump.sql…). Un fichier oublié peut donc être découvert et aspiré en quelques heures à peine après sa mise en ligne. Voici comment fermer cette porte et réagir si elle a été ouverte.
Pourquoi c’est critique
Un fichier .env exposé livre directement « les clés du royaume » : identifiants de base de données, clés d'API de services tiers (paiement, e-mail), secrets de chiffrement de l'application. Avec eux, un attaquant peut souvent prendre le contrôle total de votre site et des données de vos utilisateurs.
Un dossier .git accessible est tout aussi dangereux : il permet de reconstituer l'intégralité de votre code source — donc d'y chercher des failles — et, pire, d'en extraire des secrets qui auraient été supprimés du code mais subsistent dans l'historique des commits. Les sauvegardes (.sql, .zip) exposent quant à elles des bases de données entières. CheckCyber confirme l'exposition par la signature du contenu réel du fichier, et pas seulement par un code HTTP 200, afin d'éviter les faux positifs.
Bloquer ces fichiers au niveau du serveur
La meilleure défense est double. D'abord, ne jamais placer ces fichiers dans la racine web : un fichier .env ou un dépôt .git doivent idéalement vivre au-dessus du dossier public. Ensuite, en filet de sécurité, bloquer au niveau du serveur l'accès aux fichiers cachés (qui commencent par un point) et aux extensions de sauvegarde courantes. Conservez une exception pour /.well-known/, légitimement utilisé par security.txt et la validation des certificats.
# Bloque les fichiers cachés (sauf .well-known) et les sauvegardes
RewriteEngine On
RewriteRule "(^|/)\.(?!well-known)" - [F]
<FilesMatch "(\.env|\.bak|\.sql|\.old|backup\.zip|composer\.(json|lock))$">
Require all denied
</FilesMatch>location ~ /\.(?!well-known) { deny all; }
location ~* \.(env|bak|sql|old)$ { deny all; }Vérifier et garder le contrôle
Testez vous-même les URL les plus convoitées : votresite.fr/.env, votresite.fr/.git/config, votresite.fr/backup.zip doivent toutes renvoyer une erreur 403 ou 404, jamais du contenu. Relancez ensuite un audit CheckCyber pour balayer l'ensemble des chemins sensibles connus.
Pour éviter la récidive, intégrez ces fichiers à votre .gitignore et à votre procédure de déploiement : un fichier de sauvegarde créé « juste le temps d'une manip » est la cause la plus fréquente de ce type de fuite. Supprimez-le dès l'opération terminée.
[ FAQ // QUESTIONS FRÉQUENTES ]
▸Mon .env a été exposé, que faire en urgence ?
Considérez tous les secrets qu'il contenait comme compromis, sans exception. Changez immédiatement les mots de passe de base de données, régénérez toutes les clés d'API et les secrets de chiffrement, puis bloquez l'accès au fichier. Le simple blocage ne suffit pas : si le fichier a été accessible, supposez qu'il a été lu.
▸Comment éviter d’exposer .git ?
Ne déployez jamais le dossier .git sur le serveur de production. Si vous déployez par git pull, placez le dépôt hors de la racine web, ou bloquez explicitement l'accès à /.git/. Idéalement, déployez seulement les fichiers nécessaires (build), pas le dépôt complet.
▸Bloquer le fichier suffit-il après une exposition ?
Non. Bloquer l'accès empêche de futures lectures, mais ne fait rien pour les secrets déjà potentiellement compromis. La règle est : tout secret ayant été exposé doit être révoqué et régénéré, car vous ne pouvez pas savoir s'il a été récupéré.
[ PASSEZ À L’ACTION ]
Votre site est-il concerné ?
Lancez un audit de surface gratuit et obtenez en quelques secondes la liste exacte de vos failles, avec le correctif pour chacune. Anonyme, sans inscription.
▶ Auditer mon site[ À LIRE AUSSI ]
[ CheckCyber // MIS À JOUR LE 2026-06-29 ]