Comment nettoyer les identifiants exposés dans Git avec git-filter-repo et faire tourner les tokens

Le vrai problème

#

Récemment, j’ai réalisé que j’avais pusheé un fichier .env contenant des identifiants d’API dans un référentiel privé. Bien qu’il soit privé, ce n’est pas une excuse. Un accès compromis, un référentiel devenant public, ou simplement un audit de sécurité aurait exposé mes tokens. J’ai appris que je ne peux pas faire confiance à la suppression de fichiers dans les commits ultérieurs—Git conserve tout l’historique.

Pourquoi git-filter-repo

#

Il y a des années, j’aurais utilisé git filter-branch, mais c’est lent et sujet aux erreurs. git-filter-repo est l’outil moderne recommandé par les mainteneurs de Git. C’est rapide, précis et dispose de meilleures options pour ce travail.

Installation

#

Sur mon serveur Debian :

apt-get install git-filter-repo

Ou avec pip :

pip3 install git-filter-repo

Étape 1 : Identifier les dégâts

#

D’abord, je dois savoir quels commits contiennent des identifiants. Je recherche des modèles suspects :

git log --all --oneline | head -20
git log -p --all | grep -i "token\|password\|api_key" | head -10

Je vérifie également quels fichiers sensibles se trouvent dans l’historique :

git log --all --full-history -- ".env"
git log --all --full-history -- "config.yml"

Dans mon cas, j’ai découvert que .env avait été commitié 3 fois et un fichier credentials.json 2 fois.

Étape 2 : Faire une sauvegarde

#

Je ne fais jamais cela sans sauvegarde :

cd /path/to/my/repo
git clone --mirror . backup-mirror.git

Si quelque chose se passe mal, j’ai une copie complète du référentiel avec tout son historique.

Étape 3 : Nettoyer les fichiers spécifiques

#

J’exécute git-filter-repo pour supprimer les fichiers sensibles de l’historique complet :

git-filter-repo --invert-paths --path .env --path credentials.json

Le paramètre --invert-paths signifie que cela conserve tout SAUF ce que je spécifie. C’est l’inverse de ce que cela semble être, mais cela fonctionne parfaitement.

Le processus prend quelques secondes et réécrit tout l’historique. À la fin, je vois :

Processed 47 commits
New history has 47 commits

Étape 4 : Forcer le push (avec prudence)

#

Puisque j’ai réécrit l’historique, j’ai besoin de faire un push forcé. Sur un serveur personnel où je suis le seul dev, c’est sûr :

git push origin --force --all
git push origin --force --tags

Si c’est un référentiel partagé, je me coordonne avec l’équipe pour que tout le monde fasse git reset --hard origin/main après.

Étape 5 : Renouveler les identifiants compromis

#

Les identifiants qui étaient dans Git ne s’y trouvent plus, mais je dois supposer qu’ils ont été compromis. Je renouvelle tous les tokens :

1. Clés d’API : Je révoque les anciennes dans le panneau de l’API et en génère de nouvelles
2. Mots de passe : Je change le mot de passe de tout service utilisant ces identifiants
3. Tokens de BD : Je régénère les identifiants des bases de données
4. Clés SSH : S’ils étaient exposés, je génère de nouvelles paires

Je documente ces changements dans un fichier privé (pas dans Git) :

2026-05-19 - Rotación de credenciales post-exposición
- API key antigua: revocada, nueva generada
- Token DB: regenerado
- Contraseña servicio X: cambiada

Étape 6 : Prévention future

#

J’ajoute des règles à .gitignore (qui est maintenant propre) :

.env
.env.local
credentials.json
secrets/

Je configure également un hook pre-commit pour détecter les modèles dangereux :

git config core.hooksPath .githooks

Et je crée .githooks/pre-commit :

#!/bin/bash
if git diff --cached | grep -iE "(password|token|api_key|secret)" && \
   ! git diff --cached | grep ".gitignore"; then
    echo "⚠️ Posible credencial detectada. Abortando."
    exit 1
fi

Conclusion

#

Le nettoyage prend 10 minutes. Le renouvellement des identifiants, un peu plus. Mais c’est du temps bien investi. Sur un serveur personnel, je n’ai aucune excuse pour être négligent avec les secrets. Maintenant j’utilise des variables d’environnement et des fichiers locaux qui ne vont jamais dans Git.

Leçon apprise : Les secrets ne vont jamais dans le contrôle de version, même pas “privé”. Point final.

Équipement recommandé

#

• YubiKey 5 NFC — Clé de sécurité physique pour SSH et GitLab — élimine le risque de tokens volés
• Disque dur externe 2 To — Sauvegarde des référentiels avant les opérations destructrices comme git-filter-repo

Liens d’affiliation. Pas de coût supplémentaire pour toi.