Clé API ou fichier .env poussé sur GitHub : corriger la fuite

Révoquez ou remplacez d’abord le secret chez son fournisseur. Supprimer le fichier ou réécrire Git n’invalide pas une clé exposée.

Couper l’accès et remettre le service en état

Dans la console du fournisseur, invalidez la clé et créez un remplacement avec les droits nécessaires seulement. Mettez à jour les secrets de déploiement, de CI et de développement concernés, puis redéployez ou redémarrez les services qui chargent ces valeurs au lancement.

Consultez les journaux d’utilisation, les opérations et la consommation depuis l’exposition. Notez la période et les systèmes concernés, sans recopier la valeur du secret dans un ticket ou un chat. Pour un incident d’équipe, prévenez la personne responsable de ces accès.

La marche à suivre varie selon le fournisseur et le type d’identifiant : une clé privée, un jeton de session et un mot de passe de base de données n’ont pas les mêmes conséquences. Suivez aussi sa procédure de révocation.

Retirer le fichier des prochains commits

À la racine du dépôt, ajoutez à .gitignore les motifs adaptés :

.env
.env.*
!.env.example

Conservez dans .env.example uniquement des noms de variables et des valeurs fictives. Vérifiez que ces motifs correspondent à votre organisation de fichiers.

Si .env est déjà suivi, retirez-le de l’index sans supprimer votre copie locale :

git rm --cached -- .env
git add .gitignore .env.example
git diff --cached --stat

Créez .env.example avant la commande git add, ou omettez-le si le projet n’en utilise pas. Si .env n’est pas suivi, git rm --cached n’est pas nécessaire. Relisez les changements localement avant de les commiter ; le diff peut encore afficher l’ancienne clé dans les lignes supprimées.

Cette correction évite les prochains commits accidentels. Elle ne purge pas l’historique.

Décider si l’historique doit être nettoyé

Une clé correctement révoquée peut suffire à neutraliser l’accès. La suppression historique reste pertinente pour d’autres données sensibles, une politique interne ou une exposition qui ne peut pas être réglée par rotation.

Une réécriture change les identifiants des commits et perturbe branches, signatures et pull requests. Coordonnez une pause des pushs avec l’équipe, inventoriez branches et tags à conserver, et préservez le travail local non poussé dans un emplacement sécurisé.

Préparer la purge dans un clone dédié

Installez git-filter-repo selon sa documentation officielle, avec une version prenant en charge --sensitive-data-removal (2.47 ou ultérieure). Remplacez le propriétaire et le dépôt :

git clone https://github.com/PROPRIETAIRE/DEPOT.git nettoyage-depot
cd nettoyage-depot
git filter-repo --sensitive-data-removal --invert-paths --path .env

Le chemin est relatif à la racine Git et sensible à la casse. Ajoutez un --path pour chaque ancien emplacement si le fichier a été déplacé, par exemple --path backend/.env. Cette opération retire le fichier entier de l’historique traité ; pour conserver le fichier en remplaçant seulement certaines valeurs, consultez l’option --replace-text.

Contrôlez le rapport produit dans .git/filter-repo/, les branches, les tags et le contenu final. Pour les chemins traités :

git log --all -- .env backend/.env
git remote -v

Aucun commit ne doit rester pour les chemins supprimés. Complétez ce contrôle par un scanner de secrets sur l’historique : l’absence de ces chemins ne prouve pas que la clé n’a jamais été copiée ailleurs. Protégez également les rapports du scanner.

Publier uniquement après vérification

Vérifiez que origin désigne le dépôt exact. Si l’outil l’a retiré, rétablissez-le avec git remote add origin URL_DU_DEPOT. La commande suivante est réservée au clone nettoyé et à une intervention coordonnée :

git push --force --mirror origin

Ce push remplace les références distantes et peut en supprimer. Comparez l’inventaire des branches et tags avant de le lancer et assurez-vous qu’aucun collègue n’a poussé de nouveaux commits pendant l’intervention. Les protections de branches peuvent bloquer l’opération ; rétablissez toute protection temporairement ajustée après publication.

Sur GitHub, les références refs/pull/ sont en lecture seule. Les éventuels refus correspondants nécessitent le traitement décrit dans la procédure GitHub ; d’autres refus indiquent une publication incomplète.

Vérifier les autres copies et prévenir la récidive

Faites les contrôles finaux depuis un nouveau clone et confirmez chez le fournisseur que l’ancienne clé est invalide. Les collègues doivent repartir d’un clone propre ou nettoyer leur copie selon la procédure prévue : fusionner une ancienne branche peut réintroduire l’historique retiré.

Examinez aussi forks, pull requests, logs CI, artefacts et images de conteneurs. Une purge Git ne supprime pas toutes ces copies. Pour les références ou caches GitHub contenant encore des données sensibles, consultez les conditions d’intervention du support dans la procédure officielle.

Gardez les secrets dans le mécanisme prévu par l’hébergeur ou un gestionnaire de secrets. Activez la détection de secrets et la protection des pushs lorsqu’elles sont disponibles. Un .env ignoré par Git peut encore être copié dans une image ou intégré à un bundle frontend : vérifiez aussi les fichiers de build et les variables publiques.