# Un audit de 200 sites headless : des clés encore en clair dans Git

> Retour d'un audit transversal ayant révélé des secrets d'intégration versionnés par erreur dans l'historique Git de projets front, corrigé par un gestionnaire de secrets.

- Auteur : Clément Hadrot
- Publié le : 2025-06-03
- Mis à jour le : 2025-06-03
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/audit-200-sites-headless-cles-clair-git/

## L’essentiel

- Près d'un projet sur six exposait au moins un secret dans son historique
- La suppression du fichier ne suffit jamais à effacer l'historique Git
- Rotation systématique des clés découvertes plutôt que simple nettoyage

`git log -p -- .env`. Cette commande, exécutée méthodiquement sur les dépôts de 200 projets front headless au cours d'un audit transversal mené pour une agence gérant plusieurs dizaines de clients, a suffi à révéler que 31 d'entre eux contenaient, quelque part dans leur historique, un fichier `.env` committé par erreur, avec des clés d'API bien réelles : Stripe, SendGrid, tokens d'accès à des WordPress headless en production.

## Le protocole de l'audit

L'audit ne se limitait pas à vérifier l'état actuel des fichiers versionnés, mais scannait l'intégralité de l'historique Git de chaque dépôt, y compris les commits supprimés depuis mais toujours accessibles via les objets Git conservés localement ou sur la plateforme d'hébergement. Un simple `git rm .env` suivi d'un commit ne retire en rien la clé de l'historique : elle reste parfaitement lisible par quiconque clone le dépôt et parcourt ses commits précédents, ce qui explique pourquoi autant de projets, corrigés en apparence, restaient en réalité vulnérables.

## Répartition des secrets découverts

| Type de secret | Nombre de projets concernés | Gravité |
| --- | --- | --- |
| Mot de passe d'application WordPress | 14 | Élevée |
| Clé API de service tiers (paiement, email) | 11 | Critique |
| Jeton de déploiement (Vercel, Netlify) | 4 | Élevée |
| Identifiants de base de données | 2 | Critique |

> L'essentiel à retenir : Près d'un projet sur six exposait au moins un secret dans son historique ; La suppression du fichier ne suffit jamais à effacer l'historique Git ; Rotation systématique des clés découvertes plutôt que simple nettoyage

## Comment ces secrets se retrouvent dans Git

Le scénario le plus fréquent, observé sur une vingtaine de projets, était le même : un développeur crée localement un fichier `.env` pour tester rapidement une intégration, oublie de vérifier que le fichier `.gitignore` couvre bien cette extension dans ce dossier précis (parfois placé dans un sous-dossier non couvert par la règle générique), et committe l'ensemble sans s'en rendre compte lors d'un `git add .` pressé en fin de journée.

## Le correctif : purge d'historique et rotation systématique

Deux actions, dans un ordre précis, ont été appliquées à chacun des 31 projets concernés :

1. **Rotation immédiate de chaque secret découvert**, avant toute autre action. Une clé exposée dans un historique Git, même privé, doit être considérée comme compromise dès sa découverte, indépendamment de la visibilité réelle du dépôt.
2. **Purge de l'historique Git** avec l'outil `git filter-repo`, recommandé par la documentation officielle de Git en remplacement de l'ancien `filter-branch`, devenu trop lent et sujet à erreurs sur de gros historiques :

```
git filter-repo --path .env --invert-paths
git push origin --force --all
git push origin --force --tags
```

La purge d'historique, bien que technique, reste secondaire par rapport à la rotation des secrets : un secret révoqué ne présente plus de risque, même s'il reste visible quelque part dans un historique jamais nettoyé, alors qu'un historique purgé sans rotation du secret laisse la clé valide circuler ailleurs (forks, clones locaux, journaux de déploiement).

## Prévention mise en place à l'échelle de l'agence

- Adoption d'un gestionnaire de secrets centralisé (variables d'environnement injectées à la volée par la plateforme d'hébergement, jamais stockées en fichier local versionné).
- Ajout systématique d'un hook `pre-commit` avec un outil de détection de secrets, bloquant tout commit contenant un motif ressemblant à une clé d'API avant qu'il n'atteigne l'historique.
- Modèle de `.gitignore` standardisé, appliqué automatiquement à chaque nouveau projet créé par l'agence, couvrant explicitement tous les emplacements possibles de fichiers `.env`.

> La meilleure protection contre une clé committée par erreur n'est jamais un `.gitignore` bien écrit après coup, mais un outil qui bloque le commit avant même qu'il n'existe.

## En résumé

Près d'un projet sur six présentait au moins un secret exposé dans son historique Git, un taux qui a surpris jusqu'aux équipes concernées, convaincues que leurs fichiers `.gitignore` suffisaient à les protéger. Cet audit rappelle qu'un historique Git est, par nature, permanent : ce qui y entre par erreur y reste, sauf réécriture explicite, et la seule parade fiable reste la prévention en amont plutôt que le nettoyage a posteriori.