Clé API exposée dans le code : que faire, comment l'éviter

Clé API exposée dans le code : que faire en premier

Une clé API exposée dans le code ou dans un dépôt Git doit être considérée comme compromise. Il faut d’abord la révoquer et la remplacer chez le fournisseur, puis vérifier la consommation et les journaux, puis nettoyer le code et l’historique Git. Supprimer la ligne du code ne suffit pas, car l’historique garde la clé.

Une clé API est un identifiant que ton site présente à un service (IA, paiement, envoi d’e-mails, base de données) pour prouver qu’il a le droit de l’utiliser. Quiconque la lit peut s’en servir à ta place, et c’est toi qui paies ou qui réponds des conséquences.

C’est gérable : l’urgence tient en trois actions, dans un ordre précis. Le reste (nettoyage, prévention) se fait ensuite, sans panique.

Pourquoi une clé se retrouve exposée

Le cas est fréquent quand le code est généré par une IA, qui cherche d’abord à faire marcher la fonctionnalité. Les causes habituelles :

• La clé est écrite en dur dans un fichier, puis commitée.
• Un fichier .env n’est pas listé dans .gitignore et part dans le dépôt.
• Une clé secrète est préfixée NEXT_PUBLIC_ (Next.js) ou PUBLIC_ (Astro) : la valeur est alors copiée dans le JavaScript envoyé au navigateur.
• Un composant côté navigateur appelle directement le fournisseur d’IA, au lieu de passer par une route serveur.
• La clé est collée dans un message, une issue ou un exemple de documentation.

Pour le détail d’un cas réel, voir les risques de sécurité du vibe coding.

1. Révoquer et remplacer la clé chez le fournisseur

C’est la première action, avant tout nettoyage. GitHub le dit clairement : si la donnée sensible est un secret, la première étape est de le révoquer ou de le faire tourner, et une clé révoquée ne donne plus accès à rien source : GitHub Docs, 2026.

1. Connecte-toi au tableau de bord du fournisseur (section « API keys » ou « Développeurs »).
2. Crée une nouvelle clé, avec les droits minimum nécessaires.
3. Mets-la dans les variables d’environnement de ton hébergeur (voir plus bas).
4. Redéploie, vérifie que le site fonctionne.
5. Supprime l’ancienne clé.

La rotation désigne le remplacement d’une clé par une nouvelle, l’ancienne étant désactivée. Stripe recommande d’ailleurs de la pratiquer périodiquement, pas seulement après une fuite source : Stripe Docs, 2026.

2. Vérifier la consommation et les journaux

Une fois l’ancienne clé morte, regarde si quelqu’un s’en est servi.

• Fournisseur d’IA : consommation par clé, pic de jetons inhabituel, modèles que tu n’utilises pas.
• Paiement : Stripe conseille d’auditer les journaux de requêtes API pour repérer les abus source : Stripe Docs, 2026. Cherche des remboursements, des exports de clients ou des paiements que tu n’as pas déclenchés.
• Envoi d’e-mails : volume envoyé, destinataires inconnus, signalements de spam.
• Base de données : connexions depuis des adresses IP inconnues, lectures ou suppressions massives.

Si tu constates un usage anormal, plafonne le budget chez le fournisseur et conserve des captures des journaux. Si des données personnelles de clients ont pu être lues, la question dépasse la technique : voir RGPD et responsabilité.

3. Chercher où la clé est visible

Une clé peut être dans le dépôt, dans le navigateur, ou dans les deux.

• Dépôt : cherche le début de la clé dans tout le code, y compris l’historique (git log --all -S "début_de_la_clé").
• Navigateur : ouvre le site en production, puis les outils de développement (F12), onglet Réseau et Sources, et cherche la clé ou son préfixe (sk_, sk-).
• Déploiements : les anciennes versions et les environnements de prévisualisation peuvent contenir la même clé.

4. Nettoyer le code et l’historique Git

Retire d’abord la clé du code et remplace-la par une lecture de variable d’environnement. Ensuite, réécris l’historique si nécessaire.

Le principe : l’outil recommandé par GitHub, git filter-repo, supprime le fichier ou la valeur de tous les anciens commits, puis un push forcé remplace l’historique distant. La procédure demande git filter-repo 2.47 ou plus récent, pour l’option --sensitive-data-removal, donc suis la documentation GitHub sur le retrait de données sensibles plutôt qu’un tutoriel recopié.

Trois limites à connaître, toutes indiquées par GitHub :

• Les commits peuvent rester accessibles dans les clones, les forks, via leur identifiant dans des vues en cache et dans les pull requests.
• Tu ne peux pas nettoyer les clones des autres : il faut leur transmettre les instructions.
• Seul le support GitHub peut purger les vues en cache, et il n’intervient que si le risque ne peut pas être réduit en faisant tourner les identifiants.

C’est pourquoi l’étape 1 passe avant celle-ci : une clé révoquée rend le nettoyage de l’historique secondaire.

5. Distinguer clé publique et clé secrète

Une clé publique (dite « publiable » chez Stripe) est conçue pour apparaître dans une page web ou une application. Une clé secrète est un identifiant de compte qui doit rester dans l’environnement serveur source : Stripe Docs, 2026.

Le piège des frameworks : une variable préfixée NEXT_PUBLIC_ est intégrée au JavaScript client au moment du build, donc lisible dans les outils de développement source : documentation Next.js, 2026. Une clé d’IA ne doit jamais porter ce préfixe : le navigateur appelle ta route serveur, et c’est elle qui appelle le fournisseur.

6. Variables d’environnement et .gitignore

Une variable d’environnement est une valeur de configuration stockée hors du code, que le serveur lit au démarrage. Sur ton hébergeur (Vercel, Netlify), elle se règle dans les paramètres du projet, section « Environment Variables ». Pour le déploiement, voir le guide Claude Code jusqu’à Vercel.

En local :

1. Mets les clés dans un fichier .env.
2. Ajoute .env* au .gitignore avant de créer le fichier.
3. Garde un .env.example avec les noms de variables et des valeurs vides.
4. Ne coche pas les variables de production pour les déploiements de prévisualisation sans raison.

Stripe précise aussi qu’un dépôt privé ne protège pas la clé : il peut être exposé par les environnements de développement, et la compromission du poste d’un seul développeur suffit source : Stripe Docs, 2026. Pour la configuration d’une clé d’envoi d’e-mails, voir Resend pas à pas.

7. Activer la détection de secrets GitHub

Le secret scanning est la détection automatique des identifiants codés en dur dans un dépôt. Il est gratuit sur les dépôts publics, tandis que les dépôts privés d’organisation demandent l’offre GitHub Secret Protection source : GitHub Docs, 2026.

La push protection est le blocage d’un push contenant un secret avant qu’il n’atteigne le dépôt GitHub source : GitHub Docs, 2026. C’est le réglage le plus utile : il reste à retirer le secret du commit local, et le nettoyage côté serveur est évité.

La couverture grandit : la page de référence recense 530 motifs en octobre 2026 source : GitHub Docs, 2026, et 28 détecteurs ont été ajoutés en mars 2026, dont Vercel et Supabase source : GitHub Changelog, 2026. Vérifie ton fournisseur précis dans le tableau filtrable avant de t’y fier : aucun scanner ne détecte tout.

8. Donner la consigne à l’agent IA

Mets ces règles dans le fichier d’instructions du projet (voir CLAUDE.md et AGENTS.md) :

## Secrets
- N'écris jamais de clé, mot de passe ou jeton dans le code, les exemples ou les commits.
- Lis les secrets via les variables d'environnement, uniquement dans du code exécuté côté serveur.
- Ne préfixe jamais une clé secrète par NEXT_PUBLIC_ ou PUBLIC_.
- Ajoute .env* au .gitignore avant de créer un fichier .env.
- Si le navigateur a besoin d'un service, crée une route serveur qui l'appelle.
- Avant chaque commit, signale tout fichier contenant une chaîne ressemblant à une clé.

Relis ensuite le diff avant de valider : la consigne réduit le risque, elle ne remplace pas la relecture.

Récapitulatif : situation et action

FAQ

Quand passer la main à un pro

Fais-toi aider si les journaux montrent un usage que tu ne reconnais pas, si une clé de base de données ou de paiement est en cause, si la clé figure dans un dépôt public depuis longtemps, ou si tu ne sais pas quels clones et déploiements la contiennent. Dans ces cas, l’enjeu est l’analyse de l’impact, pas seulement le remplacement de la clé.