Secrets en prod : stop aux .env qui traînent

On a tous fait ça. Un vendredi soir, un petit correctif, un déploiement rapide… et puis un fichier .env qui traîne quelque part. Sur le serveur. Dans un container. Dans une archive. Pire, dans un repo. Et ce truc là, c’est littéralement la boîte à bijoux de ton appli.

API keys, tokens, mots de passe de base, DSN, secrets JWT, credentials cloud. Tout. Et en prod, ça ne pardonne pas.

Je vois passer pas mal de sujets « hygiène devops » sur Le Blog Tech Pro de Samyn-Antoy ABASSE et franchement, celui ci mérite un rappel net. Pas parce que c’est sexy. Parce que c’est le genre d’erreur qui finit en incident.

Pourquoi un .env qui traîne, c’est un vrai problème

Déjà, un .env est rarement chiffré. C’est du texte. Donc si quelqu’un met la main dessus, c’est fini.

Ensuite, ce fichier aime se balader. Il se retrouve dans des snapshots, des AMI, des backups, des volumes Docker, des artifacts CI, des zip de déploiement, des logs, parfois même dans un docker image history quand c’est mal fait. Et tu ne le vois pas. Ou trop tard.

Et il y a un autre point, plus sournois : les permissions. Tu crois que ton serveur est clean, mais un user de service, un process, un pod, un exploit RCE… et le .env devient la première cible.

Le piège classique : .env commité « par accident »

Oui. Le fameux :

• tu as oublié le .gitignore
• ou tu as commité .env.example puis tu as mis des vraies valeurs dedans
• ou tu as un .env.prod que tu penses hors scope, mais non

Le minimum syndical :

gitignore .env .env.* !.env.example

Et même avec ça, ça n’empêche pas une fuite si quelqu’un fait un git add -f. Donc il faut aussi une protection côté plateforme.

Ajoute un garde fou côté git

• pre-commit hook qui refuse les fichiers .env
• secret scanning (GitHub Advanced Security, GitLab secret detection, Gitleaks, TruffleHog)
• règles de protection sur la branche main

Ce n’est pas « de la parano ». C’est juste… la vraie vie.

En prod, le .env ne devrait pas être ton système de secrets

Le .env, c’est pratique en local. En prod, tu veux idéalement :

• des variables d’environnement injectées par l’orchestrateur
• ou un secret manager
• ou au minimum un fichier de conf hors webroot, avec permissions strictes, et rotation

Option 1 : variables injectées (docker, systemd, kubernetes)

Docker compose :

yaml services: app: image: monapp:latest environment: - DB_HOST=db - DB_USER=${DB_USER} secrets: - db_password secrets: db_password: file: ./secrets/db_password.txt

Systemd (simple et efficace) :

ini [Service] EnvironmentFile=/etc/monapp/monapp.env

Et là, tu verrouilles :

bash sudo chown root:root /etc/monapp/monapp.env sudo chmod 600 /etc/monapp/monapp.env

Kubernetes : utilise Secret, et si tu peux, ajoute un outil type Sealed Secrets ou External Secrets Operator pour ne pas stocker de secret en clair dans Git.

Option 2 : secret manager

AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault. Oui, ça ajoute une brique. Mais tu gagnes :

• rotation
• audit
• droits fins (IAM)
• révocation rapide

Et surtout, tu arrêtes de transporter des secrets comme des fichiers.

Stopper les dégâts : scanner ce qui existe déjà

Avant de « faire mieux », il faut voir ce qui est déjà exposé.

Cherche les .env sur tes serveurs

bash sudo find / -type f -name ".env*" 2>/dev/null

Puis inspecte les permissions :

bash stat /chemin/vers/.env

Si tu trouves un .env dans un dossier servi par Nginx ou Apache, là c’est l’alerte rouge. Tu peux avoir une fuite via une mauvaise config, ou un alias, ou un artifact statique.

Vérifie que ton serveur web bloque bien

Nginx, exemple :

nginx location ~ /.env { deny all; return 404; }

Ça ne remplace pas une vraie gestion des secrets, mais ça évite une catastrophe bête.

Et si tu as déjà fuité un secret

Règle numéro 1 : ne « change pas juste le mot de passe » à moitié.

Fais ça :

1. révoque et régénère le secret (token, clé API, mot de passe)
2. purge les caches et redeploie sans le secret exposé
3. cherche les usages inconnus (logs API, IAM, facturation)
4. ajoute un scan automatisé dans ta CI
5. note l’incident, même en interne, pour éviter de refaire pareil

Et oui, même si « personne n’a vu ». Tu n’en sais rien.

Petite checklist rapide pour ne plus te faire avoir

• .env uniquement en local
• .env.example sans vraie valeur, jamais de token réel
• secrets injectés par l’infra, pas par des fichiers dans le code
• permissions strictes si fichier nécessaire (600, owner root)
• secret scanning dans CI
• rotation périodique des secrets importants
• blocage côté Nginx/Apache des fichiers cachés sensibles

Pour finir

Tu peux avoir le meilleur firewall du monde. Si ton .env traîne, tu as laissé la porte du coffre ouverte.

Si tu veux, je peux faire une version « check prod en 15 minutes » à copier coller, adaptée à ton stack (Docker, Kubernetes, VM classique). Et si ce genre de contenu te parle, passe sur https://monblog-sa-abasse.blogspot.com, j’y poste régulièrement des guides un peu terrain, un peu imparfaits, mais utiles.

Questions fréquemment posées

Pourquoi un fichier .env qui traîne sur un serveur est-il si dangereux ?

Un fichier .env contient des informations sensibles comme des clés API, mots de passe et secrets JWT. Souvent non chiffré, il peut être facilement lu s'il est accessible. De plus, ce fichier peut se retrouver dans des snapshots, backups, containers ou logs, augmentant les risques de fuite et d'exploitation en production.

Quels sont les pièges classiques liés au commit accidentel d'un fichier .env dans un dépôt Git ?

Les erreurs fréquentes incluent l'oubli d'ajouter .env au .gitignore, le fait de commiter un fichier .env.example avec des vraies valeurs, ou de penser qu'un fichier comme .env.prod est hors scope. Ces erreurs exposent directement les secrets dans le code source.

Quelles sont les bonnes pratiques pour éviter que le fichier .env soit commité par erreur ?

Il est recommandé d'ajouter au minimum dans le .gitignore : .env, .env.* et !.env.example. En complément, mettre en place des hooks pre-commit qui refusent les fichiers .env, utiliser des outils de secret scanning (GitHub Advanced Security, Gitleaks...), et protéger la branche principale avec des règles strictes.

Comment gérer les secrets en production sans utiliser un fichier .env ?

En production, il vaut mieux injecter les variables d'environnement via l'orchestrateur (Docker Compose, systemd, Kubernetes) ou utiliser un gestionnaire de secrets dédié (AWS Secrets Manager, HashiCorp Vault...) offrant rotation, audit et contrôle d'accès fin. Sinon, stocker le fichier de configuration hors du webroot avec des permissions strictes et rotation régulière.

Comment scanner et identifier les fichiers .env déjà présents sur mes serveurs ?

Utilisez une commande comme sudo find / -type f -name ".env*" 2>/dev/null pour localiser tous les fichiers .env. Ensuite, vérifiez leurs permissions avec stat /chemin/vers/.env. Si un .env se trouve dans un dossier accessible via votre serveur web (Nginx ou Apache), c'est une alerte majeure à corriger rapidement.

Comment configurer Nginx pour bloquer l'accès aux fichiers .env ?

Ajoutez une règle dans votre configuration Nginx telle que : location ~ /.env { deny all; return 404; }. Cette directive empêche toute requête HTTP visant à accéder aux fichiers commençant par '.env', réduisant ainsi le risque de fuite via une mauvaise configuration du serveur web.