Que faire lorsque vos clés API se retrouvent dans un dépôt
Vous avez poussé du code sur GitHub et réalisé quelques secondes plus tard que votre clé API l’accompagnait. Peut-être que GitHub vous a envoyé une alerte. Peut-être que GitGuardian vous a envoyé un e-mail. Quoi qu’il en soit, vous devez maintenant gérer des secrets exposés dans des applications frontend—et le temps presse.
Voici l’élément critique que la plupart des développeurs comprennent mal : supprimer la clé de votre dernier commit ne résout pas le problème. L’historique Git préserve tout. Des forks peuvent déjà exister. Des bots automatisés scannent les dépôts publics quelques secondes après un push.
Cet article couvre exactement ce qu’il faut faire lorsque des clés API sont divulguées sur GitHub, comment distinguer les secrets véritablement sensibles des clés client publiques, et comment empêcher que cela ne se reproduise.
Points clés à retenir
- Révoquez et faites pivoter les secrets exposés immédiatement—le nettoyage de l’historique Git est secondaire puisque la clé est déjà compromise.
- Faites la distinction entre les clés client publiques (conçues pour une utilisation dans le navigateur) et les véritables secrets (identifiants privilégiés nécessitant une action urgente).
- L’historique Git préserve tout, donc supprimer un commit ne retire pas le secret des forks, caches ou clones existants.
- Activez la protection push de GitHub pour bloquer les commits contenant des secrets avant qu’ils n’atteignent votre dépôt.
- Ne stockez jamais de clés privilégiées dans le code frontend—utilisez plutôt des routes API côté serveur ou des proxies backend.
D’abord, comprenez ce que vous avez réellement exposé
Toutes les clés ne présentent pas le même risque. Avant de paniquer, identifiez quel type d’identifiant a fuité.
Les clés client publiques sont conçues pour être visibles. Les clés API Google Maps restreintes à des domaines spécifiques, les jetons d’analyse, ou les clés explicitement préfixées pour une utilisation côté client (comme NEXT_PUBLIC_ dans Next.js ou VITE_ dans Vite) sont destinées à être intégrées dans les bundles du navigateur. Elles devraient toujours avoir des restrictions d’utilisation, mais leur exposition n’est pas catastrophique.
Les véritables secrets accordent un accès privilégié : clés secrètes Stripe, identifiants AWS, chaînes de connexion aux bases de données, ou toute clé pouvant lire/écrire des données sensibles ou engendrer des frais. Ceux-ci nécessitent une action immédiate.
Cette distinction est importante car votre réponse doit correspondre à la gravité.
Réponse immédiate : révoquer et faire pivoter d’abord
Lorsque vous avez divulgué un véritable secret, le nettoyage de l’historique est secondaire. Votre première priorité est de faire pivoter les clés API compromises.
Étape 1 : Révoquez immédiatement la clé exposée. Connectez-vous au tableau de bord de votre fournisseur d’API et supprimez ou désactivez l’identifiant compromis. N’attendez pas d’avoir nettoyé l’historique Git—la clé est déjà compromise.
Étape 2 : Générez une nouvelle clé avec une portée minimale. Appliquez le principe du moindre privilège. Restreignez par IP, domaine ou points de terminaison API spécifiques lorsque c’est possible.
Étape 3 : Mettez à jour votre application. Déployez la nouvelle clé dans vos environnements avant que votre application ne cesse de fonctionner.
Certains fournisseurs cloud désactivent automatiquement les identifiants qu’ils détectent dans les dépôts publics. Par exemple, Google Cloud peut automatiquement désactiver les clés de compte de service exposées par défaut. D’autres, notamment AWS, vous notifient généralement mais ne révoquent pas systématiquement les clés automatiquement. Tous ces fournisseurs participent au programme partenaire de détection de secrets de GitHub. Ne comptez pas sur l’automatisation—agissez immédiatement de toute façon.
Pourquoi supprimer le commit ne suffit pas
Git n’oublie jamais. Même si vous supprimez le secret de votre branche actuelle, il subsiste dans :
- Les commits précédents accessibles via
git log - Les forks créés avant votre correction
- Les clones existants récupérés par d’autres utilisateurs ou bots
- Tous les miroirs créés avant la suppression
C’est pourquoi la révocation vient en premier. Le nettoyage de l’historique est un confinement, pas une remédiation.
Si vous devez nettoyer l’historique, des outils comme git filter-repo ou BFG Repo-Cleaner peuvent vous aider. Mais comprenez que si votre dépôt a été public pendant un certain temps, supposez que le secret a été capturé.
Discover how at OpenReplay.com.
Détection de secrets et protection push de GitHub
GitHub offre une protection de première classe contre ce problème précis. La détection de secrets et la protection push sont disponibles pour tous les dépôts publics et pour les dépôts privés via GitHub Secret Protection (également inclus dans GitHub Advanced Security).
La détection de secrets détecte les modèles d’identifiants connus dans votre dépôt et vous alerte automatiquement, vous et/ou le fournisseur.
La protection push va plus loin—elle bloque les commits contenant des secrets détectés avant qu’ils n’atteignent le dépôt. C’est le mécanisme de prévention le plus efficace disponible.
Activez les deux dans les paramètres de votre dépôt sous Settings → Code security and analysis, ou consultez la documentation officielle sur GitHub Secret Protection.
Le piège des variables d’environnement frontend
Voici une erreur qui piège de nombreux développeurs React, Vue et Next.js : les variables d’environnement préfixées pour une utilisation client ne sont pas des secrets.
Les variables comme REACT_APP_*, NEXT_PUBLIC_* ou VITE_* sont intégrées directement dans votre JavaScript. N’importe qui peut ouvrir les DevTools et les trouver. Elles ne sont pas cachées—elles sont simplement organisées.
Si une clé accorde un accès privilégié, elle ne peut pas résider dans le code frontend. Point final.
Stratégies de prévention pour les équipes frontend
Conservez les clés privilégiées côté serveur. Utilisez des routes API, des fonctions serverless ou un proxy backend. Votre frontend authentifie les utilisateurs ; votre backend détient les secrets.
Activez la protection push. Cela détecte les erreurs avant qu’elles ne deviennent des incidents.
Utilisez des hooks pre-commit. Des outils comme gitleaks ou detect-secrets scannent les modifications en attente localement.
Ajoutez une détection en CI. Exécutez la détection de secrets dans votre pipeline comme filet de sécurité.
Restreignez les clés de manière agressive. Même les clés client publiques devraient être limitées par domaine, IP ou portée d’API.
Conclusion
Lorsque des clés API fuient, la rapidité compte plus que la perfection. Révoquez d’abord, faites pivoter immédiatement, puis nettoyez l’historique comme étape secondaire. Ne confondez pas les clés client publiques avec les véritables secrets, et ne faites jamais confiance aux variables d’environnement pour cacher quoi que ce soit dans les builds frontend.
Activez la protection push de GitHub dès aujourd’hui. C’est le moyen le plus simple de garantir que ce problème ne se reproduise plus jamais.
FAQ
Révoquez ou désactivez immédiatement la clé exposée via le tableau de bord de votre fournisseur d'API. N'attendez pas de nettoyer d'abord votre historique Git. La clé est déjà compromise dès qu'elle a été poussée vers un dépôt public, et les bots automatisés peuvent la capturer en quelques secondes. Après la révocation, générez une nouvelle clé et mettez à jour votre application.
Non. Git préserve tout l'historique, donc le secret reste accessible dans les commits précédents, les forks, les clones existants et toutes les copies effectuées avant votre correction. Supprimer ou modifier le commit ne le retire que de la pointe de la branche actuelle. Vous devez révoquer la clé indépendamment de tout nettoyage d'historique que vous effectuez par la suite.
Non. Ces variables d'environnement préfixées sont intégrées directement dans votre JavaScript frontend et sont visibles par quiconque ouvre les DevTools du navigateur. Elles sont destinées aux valeurs de configuration publiques, pas aux secrets. Toute clé accordant un accès privilégié doit être stockée côté serveur et accessible via des routes API ou des proxies backend.
Activez la protection push de GitHub pour bloquer les commits contenant des secrets détectés avant qu'ils n'atteignent votre dépôt. Utilisez des hooks pre-commit avec des outils comme gitleaks ou detect-secrets pour scanner les modifications localement. Ajoutez la détection de secrets à votre pipeline CI comme filet de sécurité supplémentaire. Ces couches fonctionnent ensemble pour détecter les erreurs rapidement.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
