Fichier .env exposé dans un dépôt ou une archive livrée : le risque de fuite de secrets

Le .env liste des variables d’environnement sous forme de paires CLE=valeur, destinées à être chargées par une application au démarrage plutôt que codées en dur dans le programme — une convention popularisée par la bibliothèque “dotenv” et consacrée par les principes du Twelve-Factor App pour séparer la configuration du code source.

Cette séparation, précisément parce qu’elle regroupe tous les secrets d’une application dans un seul fichier facile à identifier, en fait aussi une cible de fuite récurrente. Les deux vecteurs les plus fréquents sont un .gitignore oublié ou mal configuré au démarrage d’un projet (le fichier est alors versionné dès le premier commit, avant que quiconque n’y pense), et un script de livraison ou de déploiement qui compresse l’intégralité d’un dossier de projet pour l’envoyer à un client ou un prestataire, sans exclure les fichiers de configuration locale.

Un .env n’a aucune signature binaire : c’est du texte indiscernable de n’importe quel autre fichier de configuration au niveau des octets. Un contrôle basé sur le contenu du fichier ne peut donc pas le repérer comme “sensible” par sa seule forme — la protection se joue en amont, au niveau du processus (règle .gitignore, détection de secrets intégrée à la CI, hook de pré-commit), pas au niveau de l’identification du fichier lui-même.

Une fois un .env réellement poussé vers un dépôt public, supprimer le fichier ou réécrire l’historique Git ne suffit pas : des robots spécialisés scrutent en continu les dépôts publics à la recherche de secrets exposés, et un identifiant qui a été rendu public doit être considéré comme compromis dès sa publication, quelle que soit la rapidité de sa suppression ultérieure. La seule remédiation fiable est de révoquer et régénérer chaque identifiant qu’il contenait.

Pour tester le comportement de chargement de configuration d’une application sans manipuler de vrais secrets, un fichier généré avec des valeurs de test suffit à vérifier que le mécanisme fonctionne, sans exposer d’identifiant réel dans un environnement de test ou une chaîne d’intégration continue.