Fichier .env lisible : clés et base dans la nature
Un `.env` lisible, c'est la base, le SMTP, les clés API dans la nature. Tournez tout ce qui y figurait. L'exposition du fichier est un incident à part, parfois plus grave que le défacement qui l'a fait découvrir.
Tournez toutes les secrets qui y figuraient : base, SMTP, API. Le .env exposé est un incident à part, parfois plus grave que le défacement.
Ce qu'un `.env` contient vraiment
Mot de passe de base, utilisateur MySQL, clés APP, jetons Stripe, secrets SMTP, URL de webhook, parfois une clé AWS. Ce n'est pas un fichier de « config anodine ». C'est le trousseau. Un défacement se voit. Un `.env` lu se tait — jusqu'à la prochaine connexion avec vos clés.
WordPress n'en a pas toujours un (`wp-config` joue ce rôle). Les stacks Laravel, Symfony, Node, les headless, les outils de build, si. Un site « vitrine WP » peut avoir un `.env` dans un dossier d'app à côté. Cherchez-le. WP headless.
Si `wp-config.php` était public (mauvais MIME, backup `wp-config.php.bak`), même famille. wp-config.
Comment il se retrouve en 200
DocumentRoot mal calé (le projet est la racine, pas `/public`). Un dépôt cloné « vite fait » en prod. Un zip de backup. Un serveur qui sert les fichiers dot. Ce n'est pas une faille Laravel mystérieuse : c'est un déploiement. Fréquent après une « mise en ligne rapide ».
Les bots demandent `/.env` comme ils demandent `/backup.zip`. S'il répond, il est parti. Archives publiques.
Après un piratage, l'attaquant a pu le lire même sans 200 public (FTP, shell). Le 200 aggrave (tout le monde). L'accès serveur suffit pour tourner. On assume la lecture dès que le fichier était atteignable d'une des deux façons.
Tourner, pas « déplacer et oublier »
Retirer le 200 est urgent et insuffisant. Chaque secret du fichier se régénère chez le fournisseur (base, Stripe, SMTP, AWS), puis on met à jour le nouveau `.env` hors web. Garder les mêmes mots de passe « parce qu'on a déplacé le fichier » laisse les copies déjà téléchargées valides.
L'ordre : panel / base d'abord si le mot de passe y était, puis APIs, puis SMTP (sinon la file d'envoi continue avec le secret lu). Même esprit que panel ≠ CMS.
Les jetons de deploy (Vercel, GitHub) dans le `.env` : rotation, revue des déploys. Un rebuild avec les anciennes clés republie le problème.
- Base et utilisateur MySQL / Postgres.
- PSP, SMTP, buckets, webhooks.
- APP_KEY / secrets de session : régénérer, invalider les sessions.
Laravel, Node, et le voisin WordPress
Laravel : DocumentRoot = `public/`, jamais la racine du repo. Node : les `.env` de prod ne voyagent pas dans le front bundle — vérifiez ce que le build a cuit. Un secret dans un JS public n'est plus un `.env`, c'est pire (tout visiteur).
Deux apps sur le même compte : le `.env` de l'une ouvre parfois la base de l'autre (même mot de passe). Inspectez le voisin. WP + Presta.
Docker : un `.env` à la racine du compose, monté, parfois copié dans une image. Relisez ce qui est public sur le registre et sur le vhost.
Ce que le constat doit lister
Fichier trouvé, URL, dates (logs, `Last-Modified`), catégories de secrets (pas les secrets eux-mêmes dans un PDF qui voyage). Secrets tournés, date. Si un dump SQL était à côté, le lier. C'est le document pour l'assureur et, si besoin, le volet données.
N'écrivez pas les mots de passe dans le constat. Écrivez « SMTP tourné le … ». Le constat se forward.
Qui nous sommes : on vous dit quoi tourner, on ne garde pas une copie du `.env` « pour plus tard ».
Données clients : le saut n'est pas automatique
Un `.env` donne les clés pour aller chercher les données, il n'est pas la base. Si la base était joignable depuis l'extérieur avec ces identifiants (0.0.0.0, pas d'IP allow), le plausible d'exfiltration monte. Si la base n'écoute que localhost et que seul le panel était pris, le scénario change. On le dit au conditionnel, on ne dément pas trop tôt.
Le volet fuite s'ouvre quand l'accès aux tables est plausible, pas au seul mot « .env ». Votre conseil, notre chronologie.
Les emails dans le `.env` (comptes de service) se tournent. Ce ne sont pas vos clients ; ce sont des portes.
Empêcher le prochain 200
DocumentRoot correct, règles serveur pour ne pas servir les fichiers dot, `.env` hors web, pas dans Git (et si déjà commité : rotation, historique). Les déploiements passent par des variables d'environnement du panel / de la CI, pas un fichier traînant.
Test : l'URL `/.env` doit 404 ou 403, pas 200, après clôture. Ajoutez-le à la surveillance un temps.
Un staging avec le `.env` de prod est un incident en puissance. Secrets distincts. Staging.
Dans le même passage que `.git` et les zip
Une passe, une liste : `.env`, `.git`, zip, sql, phpinfo, Adminer. Pas cinq rendez-vous. `.git`, phpinfo.
Ne « profitez pas » pour une refonte. Sortez le fichier, tournez, fermez l'entrée du piratage initial. Refonte.
Déclarer : « .env était en 200 » change l'ordre de la première heure (rotation large). Dites-le. Ce n'est pas une honte, c'est un fait de déploiement.