Fichier .env exposé — la réponse à incident en 30 minutes | Scanthra

Scanthra · 6 min de lecture · Mis à jour Mai 2026

Pourquoi un fichier .env exposé est sérieux

Un fichier .env contient généralement :

• Nom d'utilisateur + mot de passe + hôte de la base de données.
• Clés API pour Stripe, AWS, SendGrid, Mailgun, OpenAI…
• Secrets de signature JWT et secrets client OAuth.
• Parfois des identifiants d'administration ou un « mot de passe DEV » utilisé en développement.

Des scanners internet comme Shodan, BinaryEdge et des dizaines de botnets collecteurs de credentials récupèrent continuellement /.env sur des millions d'hôtes. Si le tien est public, considère qu'il a déjà été lu. Le coût d'une rotation est bien inférieur au coût d'une fuite de données.

Étape 1 — Faire pivoter chaque secret du fichier

Ouvre le fichier (ou ta sauvegarde) et pour chaque entrée :

• DB_PASSWORD — change-le dans ta base de données (ALTER USER … WITH PASSWORD … sous PostgreSQL, ALTER USER … IDENTIFIED BY … sous MySQL), puis mets à jour la configuration de ton application.
• Clés API — pour chaque fournisseur, va dans le tableau de bord → Clés API → révoque la clé compromise, génère-en une nouvelle, mets à jour la configuration. Stripe, AWS et OpenAI supportent tous la rotation à chaud sans interruption.
• Secrets JWT / session — fais pivoter en sachant que cela déconnectera tous les utilisateurs. Planifie ça pendant une fenêtre à faible trafic si nécessaire, mais ne tarde pas plus de quelques heures.
• Identifiants SMTP / messagerie — fais pivoter immédiatement ; des identifiants SMTP compromis sont le vecteur de spam n°1.

Utilise un gestionnaire de mots de passe ou ton gestionnaire de secrets (AWS Secrets Manager, Doppler, 1Password, Bitwarden) pour générer les nouvelles valeurs. Ne réutilise jamais les anciens secrets.

Étape 2 — Auditer l'utilisation des clés compromises

Avant d'oublier les anciennes clés, vérifie si quelqu'un les a utilisées pendant qu'elles étaient exposées :

• Stripe : Tableau de bord → Développeurs → Événements. Filtre par ton ancienne clé. Cherche des paiements, remboursements, modifications de compte que tu n'as pas faits.
• AWS : Historique des événements CloudTrail filtré par l'ID de clé d'accès compromise. Cherche de nouveaux utilisateurs IAM, de nouvelles instances EC2, des lectures S3 de buckets inattendus, tout ce qui concerne iam:* ou ec2:RunInstances.
• SendGrid / Mailgun : Journal d'activité pour les pics, ajouts de nouveaux modèles, changements d'adresse IP.
• Base de données : logs d'audit (si activés) pour des requêtes inattendues ; vérifie pg_stat_activity pour les sessions en cours.

Si tu trouves quelque chose de suspect : c'est un incident confirmé — escalade, documente, suis ton plan de réponse à incident, et notifie les clients si des données personnelles sont impliquées. Les entités dans le périmètre NIS2 (directive UE sur la cybersécurité) doivent déposer une alerte précoce dans les 24 heures.

Étape 3 — Bloquer le chemin définitivement

Le fichier exposé vivait probablement à la racine de ton application parce que la racine web du framework est un niveau trop haut. Deux couches de défense valent mieux qu'une :

Déplace le fichier hors de la racine web :

mkdir /etc/myapp
mv /var/www/myapp/.env /etc/myapp/.env
chmod 600 /etc/myapp/.env
chown www-data:www-data /etc/myapp/.env

Mets à jour ton application pour qu'elle lise depuis le nouveau chemin.

Et bloque les fichiers cachés au niveau du serveur web :

# nginx
location ~ /\.(?!well-known) { deny all; return 404; }

# Apache
<FilesMatch "^\.">
  Require all denied
</FilesMatch>

Étape 4 — S'assurer que ça ne se reproduit jamais

• Utilise un gestionnaire de secrets en production — AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Doppler. Le fichier .env devient un outil de développement local, pas un artefact de déploiement.
• Ajoute une vérification CI qui fait échouer le build si .env est commis. git secrets, trufflehog ou gitleaks font ça.
• Installe un hook pre-commit avec detect-secrets pour que les fuites n'atteignent même pas main.
• Fais pivoter périodiquement de toute façon. Tous les 6 mois pour les clés longue durée ; immédiatement quand un membre de l'équipe quitte.

Et l'historique Git ?

Si .env a un jour été commis dans un dépôt public — même brièvement, même il y a des années — considère que les secrets sont compromis. La recherche GitHub et des milliers de scrapers de données d'entraînement l'ont. git filter-repo réécrit l'historique, mais tu dois quand même faire pivoter les valeurs, parce que des copies existent hors de ton contrôle.

La leçon ennuyeuse

Le fichier .env exposé est l'un des problèmes détectés les plus fréquents par Scanthra sur des projets PHP, Laravel, Django, Rails et Node. La cause racine est presque toujours : « j'ai suivi un tutoriel qui mettait .env à la racine du projet et j'ai oublié que le serveur web servait les fichiers statiques depuis là. » Déplacer le fichier d'un répertoire vers le haut — et ajouter la règle de blocage des fichiers cachés — ferme toute cette classe de problèmes.

Comment Scanthra détecte ça

Notre module Hidden Files vérifie une liste blanche soigneusement sélectionnée de chemins incluant .env, .env.local, .env.production, .git/config, /backup.sql, /dump.sql, /wp-config.php.bak et plus encore. Nous complétons ça avec des vérifications de magic bytes (ZIP, gzip, en-têtes SQLite) pour distinguer une vraie sauvegarde d'une page 404 qui renvoie par hasard un 200.