Skip to main content
Aller au contenu principal
Sécurité26 juillet 2026 8 min de lecture

Chiffrer les fichiers .env avant commit

Committer un .env en clair fuite tous les secrets de votre dépôt. Si une copie doit vivre dans git, chiffrez-la d'abord – voici le flux sûr.

Chiffrez tout le fichier localement avec le chiffreur AES-256-GCM. Collez, chiffrez avec une phrase de passe, enregistrez seulement le texte chiffré.

Le fichier .env qui n'aurait jamais dû être committé

Chaque développeur l'a vu : un dépôt avec un fichier .env contenant des identifiants de base de données, des clés API et un secret de production ou deux, présent dans l'historique git pour toujours.

L'historique git est un enregistrement permanent. Supprimer le fichier aujourd'hui ne le retire pas des commits passés, et tout clone, fork ou cache CI peut encore le contenir. Les attaquants scannent les dépôts publics pour exactement ces fichiers.

Le correctif commence avant l'existence du fichier : ne committez jamais de secrets en clair. Le chiffrement est le repli pour les cas où une copie doit exister dans le dépôt.

Les meilleures options avant le chiffrement

  • gitignorez le fichier – ajoutez .env et .env.* à .gitignore et ne les stagez jamais
  • Utilisez des variables d'environnement injectées par votre hébergeur, CI ou plateforme de déploiement
  • Utilisez un gestionnaire de secrets pour les valeurs de production et injectez-les à l'exécution
  • Stockez uniquement les valeurs par défaut non secrètes dans un .env.example committé, avec des espaces réservés

Remarque: Le chiffrement n'est pas une licence pour committer des secrets à la légère. C'est le motif de dernier recours pour les équipes qui ont réellement besoin d'une copie partagée et versionnée de la configuration – par exemple les configurations hors ligne ou les petites équipes sans gestionnaire de secrets.

Pourquoi AES-256-GCM pour les fichiers d'environnement

AES-256-GCM est un mode de chiffrement authentifié : il fournit la confidentialité et détecte toute altération du texte chiffré. Si le fichier est modifié dans le dépôt, le déchiffrement échoue au lieu de renvoyer silencieusement des valeurs corrompues.

Comme les fichiers .env sont généralement de petits textes, les chiffrer comme un document unique avec une phrase de passe est pratique. La phrase de passe est étirée avec PBKDF2, donc une phrase faible coûte quand même à l'attaquant un vrai calcul par supposition.

Tout peut se dérouler dans le navigateur avec l'API Web Crypto – le texte clair n'a jamais besoin d'atteindre un serveur, ce qui est exactement ce qu'exige un flux zéro connaissance.

Chiffrer un fichier .env avant de le committer

  1. Ouvrez le chiffreur AES-256-GCM.
  2. Passez en mode fichier et sélectionnez votre fichier .env, ou collez son contenu dans la zone de texte.
  3. Choisissez le chiffrement par mot de passe et saisissez une phrase de passe forte – au moins 12 caractères aléatoires, idéalement une phrase de quatre mots ou plus.
  4. Chiffrez et enregistrez la sortie comme .env.enc (ou env.enc).
  5. Supprimez le fichier en clair de l'arbre de travail et committez uniquement le texte chiffré, plus un env.example qui documente les noms de variables sans valeurs.
  6. Partagez la phrase de passe avec vos coéquipiers par un canal hors du dépôt – un gestionnaire de mots de passe, pas un message de chat ni un commentaire de PR.

Avertissement: Il n'y a aucune récupération si la phrase de passe est perdue, et aucune sécurité si elle fuite. Stockez-la dans un gestionnaire de mots de passe d'équipe, faites-la tourner au départ d'un membre et considérez que le texte chiffré ne vaut que ce que vaut la phrase de passe.

Déchiffrer quand un coéquipier récupère le dépôt

  1. Récupérez le dépôt et ouvrez le chiffreur AES-256-GCM.
  2. Sélectionnez le fichier .env.enc.
  3. Saisissez la phrase de passe partagée et déchiffrez.
  4. Copiez les valeurs dans l'environnement local ou enregistrez le fichier en clair localement – et assurez-vous qu'il est ignoré par git.

Rotation et réponse aux incidents

Chiffrer les secrets réduit l'exposition, mais si un .env en clair a déjà été committé, supposez que chaque secret qu'il contient est compromis et faites-les tourner – même si vous supprimez ou chiffrez ensuite le fichier.

Quand un coéquipier qui connaissait la phrase de passe quitte l'équipe, faites tourner la phrase de passe et rechiffrez le fichier. Mieux : faites tourner les secrets eux-mêmes pour que l'ancien texte chiffré devienne inutile.

Ajoutez un contrôle CI qui échoue quand un fichier .env en clair apparaît dans un diff. Quelques lignes de script coûtent moins cher que le nettoyage qui suit une fuite.

FAQ

Q.Chiffrer le fichier .env suffit-il ?

A.Cela protège le contenu du fichier dans le dépôt, mais ne corrige pas les phrases de passe faibles, les erreurs de partage de clés ni les secrets déjà fuités en clair. Combinez le chiffrement avec gitignore, gestionnaires de secrets et rotation.

Q.Puis-je chiffrer un seul secret au lieu de tout le fichier ?

A.Oui – chiffrez les valeurs individuellement et stockez-les comme variables d'environnement, par exemple API_KEY=$(decrypt ...). Le chiffrement de tout le fichier est plus simple pour les petites configurations ; le chiffrement par valeur offre un contrôle plus fin et se rapproche du fonctionnement des gestionnaires de secrets.

Q.Que se passe-t-il si la phrase de passe est perdue ?

A.Le texte chiffré est irrécupérable. Il n'y a pas de porte dérobée dans AES-256-GCM. Gardez la phrase de passe dans un gestionnaire de mots de passe d'équipe et traitez sa perte comme un événement de processus, pas comme un problème de récupération.

Q.J'ai déjà committé un .env en clair. Et maintenant ?

A.Faites tourner immédiatement tous les secrets de ce fichier – l'historique et les clones le contiennent encore. Puis ajoutez-le à .gitignore, chiffrez les copies futures et n'envisagez la réécriture d'historique que pour de très petits dépôts privés où vous comprenez les conséquences.

Q.Est-il sûr de chiffrer mon .env dans un outil navigateur ?

A.Uniquement si l'outil est vraiment côté client. Le chiffreur de ce site s'exécute entièrement dans votre navigateur avec l'API Web Crypto – rien n'est envoyé. Vérifiez la même propriété pour tout outil que vous utilisez : confirmez que le chiffrement se déroule localement et que la page ne fait aucune requête réseau avec vos données.

Références

  • NIST SP 800-38D – Galois/Counter Mode (GCM) : https://csrc.nist.gov/pubs/sp/800/38/d/final
  • RFC 5116 – Interface et algorithmes pour le chiffrement authentifié : https://www.rfc-editor.org/rfc/rfc5116
  • NIST SP 800-132 – Dérivation de clé par mot de passe (PBKDF2) : https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
  • Aide-mémoire OWASP sur la gestion des secrets : https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

Chiffrez votre fichier d'environnement

AES-256-GCM avec une phrase de passe, entièrement côté client. Sans envoi, sans compte.

Chiffrez d'abord, ou mieux, ne committez pas du tout

Les secrets dans git sont un passif permanent. Préférez gitignore et les gestionnaires de secrets ; quand une copie versionnée est inévitable, chiffrez le fichier localement avec une phrase de passe forte et committez uniquement le texte chiffré.

Chiffrez et déchiffrez les fichiers .env dans votre navigateur avec le chiffreur AES-256-GCM – rien ne quitte votre appareil.

chiffrer fichier envsecrets fichier envcommitter fichier envchiffrer .env aessécurité variables d'environnementsecrets dans gitchiffrer fichier de configurationchiffrement env zéro connaissance