Protéger les Clés API : Comment Éviter les Extensions VS Code Malveillantes

Le 20 mai 2026, GitHub a confirmé que des attaquants avaient volé des données d'environ 3 800 dépôts de code internes. Le point d'entrée n'était pas une faille zero-day côté serveur, mais une extension VS Code empoisonnée installée sur l'ordinateur portable d'un employé. Une fois exécutée avec les mêmes permissions que le développeur, l'extension pouvait lire le code source, les fichiers de configuration et les identifiants présents dans l'espace de travail. Pour protéger vos clés API contre ce type d'attaque, partez d'un principe simple : le risque est souvent sur la machine du développeur et dans les outils qui s'y exécutent.

Essayez Apidog aujourd’hui

TL;DR

Pour protéger les clés API contre une extension IDE compromise ou un dépôt divulgué :

• ne stockez pas de secrets actifs dans le code source ;
• ne committez jamais de fichier .env ;
• considérez .gitignore comme une aide, pas comme un contrôle de sécurité ;
• séparez les clés par environnement ;
• utilisez des identifiants à privilège minimum et durée de vie courte ;
• mettez en place une rotation planifiée ;
• stockez les secrets dans des variables d’environnement locales ou dans un gestionnaire de secrets.

Des outils comme Apidog aident à éviter les clés en clair dans le dépôt en stockant les identifiants API dans des variables d’environnement avec des valeurs locales uniquement.

Pourquoi la violation de GitHub est un signal d'alarme pour chaque développeur

L'incident GitHub ressemble à une attaque classique de chaîne d'approvisionnement. Le groupe suivi sous le nom de TeamPCP a déjà trojanisé des packages dans les écosystèmes npm, PyPI et PHP. Cette fois, la charge utile est passée par une extension VS Code.

Selon TechCrunch, les attaquants ont exfiltré des données d'environ 3 800 dépôts internes et vendent l'ensemble de données pour plus de 50 000 $ sur des forums clandestins. GitHub indique n'avoir aucune preuve que les données clients stockées hors de ces dépôts internes aient été affectées. L'enquête est en cours.

Le point important : une extension VS Code est du code exécuté avec les permissions de votre compte utilisateur. Elle peut généralement :

• lister des répertoires ;
• ouvrir et lire des fichiers ;
• surveiller les changements ;
• envoyer des requêtes réseau sortantes.

Ce comportement n'est pas forcément une vulnérabilité. C'est le modèle d'extension normal. Le problème apparaît lorsqu'une extension malveillante utilise cet accès pour collecter les secrets présents localement.

Dans un projet typique, elle peut trouver :

• un fichier .env ;
• un config/secrets.yml ;
• un token codé en dur dans un script de test ;
• ~/.aws/credentials ;
• un .npmrc contenant un token ;
• des clés SSH ;
• des fichiers de configuration CI/CD.

Le même acteur est associé à la campagne du ver npm « Mini Shai-Hulud », qui collectait des identifiants de développeurs, CI/CD, cloud et outils d'IA depuis les machines infectées. Le schéma reste le même : faire exécuter du code localement, puis chercher tout ce qui ressemble à un secret.

Nous avons déjà analysé des expositions similaires dans les leçons de sécurité API tirées de la violation de Vercel et dans le guide de sécurité de la chaîne d'approvisionnement npm.

La bonne question à se poser est directe :

Si une extension malveillante s'exécutait dans votre éditeur maintenant, avec quels secrets repartirait-elle ?

Les clés codées en dur et les fichiers .env committés créent une vulnérabilité durable

La plupart des fuites d'identifiants ne sont pas sophistiquées. Elles viennent souvent d'un développeur qui colle une clé « temporairement » dans le code, ou d'un fichier .env committé par erreur.

Exemple classique :

import requests

# Test rapide du point de terminaison de paiement
STRIPE_KEY = "sk_live_51Qk2mNExampleKeyDoNotShipThis"

response = requests.post(
    "https://api.stripe.com/v1/charges",
    auth=(STRIPE_KEY, ""),
    data={"amount": 2000, "currency": "usd", "source": "tok_visa"},
)

print(response.json())

Cette clé sk_live_ est maintenant :

• dans votre répertoire de travail ;
• lisible par les outils locaux ;
• potentiellement dans l'historique Git ;
• récupérable par toute personne ou tout outil ayant accès au dépôt.

Le fichier .env améliore la situation, mais ne règle pas tout :

# .env chargé à l'exécution, jamais destiné à être livré
DATABASE_URL=postgres://app_user:[e-mail]:5432/payments
STRIPE_SECRET_KEY=sk_live_51Qk2mNExampleKeyDoNotShipThis
OPENAI_API_KEY=sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890
AWS_ACCESS_KEY_ID=AKIA4EXAMPLE7QRSTUVW
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
JWT_SIGNING_SECRET=8f2a91c4e7b6d3508f2a91c4e7b6d350

C'est mieux que le codage en dur, car les secrets ne sont pas directement dans le code. Mais le fichier reste :

• en texte clair ;
• dans l'espace de travail ;
• lisible par un processus local ;
• accessible à une extension compromise.

Une extension malveillante ne fait pas la différence entre app.py et .env. Ce sont deux fichiers. Les deux peuvent être lus avec une opération de type fs.readFileSync.

Le pire cas reste le fichier .env committé. Une fois présent dans l'historique Git, le secret reste récupérable même si vous supprimez la ligne plus tard. C'est particulièrement dangereux si le dépôt est public, mis en miroir ou exposé lors d'une violation.

Pour approfondir ce point, consultez notre article sur la documentation API et la sécurité des dépôts Git.

.gitignore n'est pas un contrôle de sécurité

Ajouter .env à .gitignore est nécessaire, mais insuffisant.

.gitignore indique seulement à Git d'ignorer certains fichiers non suivis lors d'un git add. Il ne protège pas le fichier sur le disque et ne supprime pas les secrets déjà committés.

Trois limites importantes :

1. Il ne s'applique pas aux fichiers déjà suivis. Si .env a déjà été committé, Git continue à le suivre. Vous devez exécuter :

   git rm --cached .env
   git commit -m "Remove .env from repository"

Mais le secret reste dans l'historique.

1. Il ne protège pas le fichier local.
   
   Le fichier .env reste en clair dans votre espace de travail. Une extension compromise lit le système de fichiers, pas l'index Git.

2. Il peut être contourné.
   
   git add -f .env force l'ajout du fichier. Certaines interfaces graphiques ou configurations de sous-répertoires peuvent aussi provoquer des erreurs.

Pour vérifier si .env est déjà dans votre historique :

# Liste les commits ayant touché .env
git log --all --full-history --oneline -- .env

# Recherche des valeurs sensibles dans l'historique
git log -p --all -- .env | grep -iE "key|secret|token|password"

Si ces commandes retournent quelque chose, traitez les secrets comme compromis.

Plan d'action :

1. faites pivoter les clés exposées ;
2. supprimez les fichiers concernés de l'historique avec un outil comme git filter-repo ;
3. coordonnez le push forcé avec l'équipe ;
4. déplacez les secrets actifs hors des fichiers en texte clair.

.gitignore reste utile pour éviter des erreurs simples. Mais ce n'est pas une barrière de sécurité.

Réduire le rayon d'impact : limiter, séparer, raccourcir, faire pivoter

Vous ne pouvez pas garantir qu'aucun identifiant ne fuira jamais. En revanche, vous pouvez faire en sorte qu'un identifiant divulgué ait peu de valeur.

1. Limiter la portée des secrets par environnement

N'utilisez jamais la même clé pour développement, staging et production.

À la place :

• développement : clé sandbox, données de test ;
• staging : clé dédiée au staging ;
• production : clé de production, jamais copiée sur un laptop.

Si une clé de développement fuit, l'attaquant atteint un bac à sable, pas vos systèmes de production.

2. Séparer réellement les environnements

La séparation ne consiste pas seulement à changer trois valeurs de clés. Les environnements doivent être isolés.

Exemples :

• la base de données de développement ne doit pas être une copie connectée à la production ;
• le paiement en staging doit utiliser le mode test du fournisseur ;
• une configuration dev ne doit pas pouvoir pointer vers la production via une simple variable.

Une bonne séparation rend la gravité d'une fuite beaucoup plus claire : vous savez immédiatement quel environnement est concerné.

3. Utiliser des clés à privilège minimum et durée de vie courte

Deux propriétés comptent : les permissions et la durée de vie.

Privilège minimum

Une clé doit avoir uniquement les droits nécessaires.

Exemples :

• une build frontend lisant un catalogue public doit être en lecture seule ;
• une clé de test ne doit pas accéder à la facturation ;
• une clé de service ne doit pas être administrateur si elle n'en a pas besoin.

De nombreux fournisseurs proposent des clés limitées ou des tokens à grain fin. Pour comparer les approches, consultez notre article sur les clés API versus OAuth.

Durée de vie courte

Une clé qui expire en une heure est beaucoup moins utile à un attaquant. Les clés statiques qui vivent indéfiniment sont plus dangereuses, car elles restent valides jusqu'à leur révocation manuelle.

Préférez :

• des tokens courts générés à la demande ;
• des expirations explicites ;
• des clés long terme uniquement lorsqu'elles sont inévitables.

4. Faire pivoter selon un calendrier

La rotation ne doit pas être une réaction paniquée après incident. Elle doit être routinière.

Exemple de base :

• clés de production à privilège élevé : rotation mensuelle ;
• clés moins sensibles : rotation trimestrielle ;
• clés exposées : rotation immédiate.

La rotation planifiée :

• limite la durée d'exploitation d'une fuite non détectée ;
• valide régulièrement votre procédure ;
• rend la réponse à incident plus prévisible.

Pour aller plus loin, consultez notre guide des outils de gestion des clés API.

Garder les identifiants dans les variables d'environnement Apidog, pas dans l'espace de travail

Apidog propose une extension VS Code et son propre serveur MCP. L'objectif n'est pas de prétendre qu'un outil côté client est immunisé contre les attaques de chaîne d'approvisionnement. Aucun ne l'est.

Le point important est l'emplacement des secrets.

Dans un workflow API classique, vous avez besoin de :

• tokens Bearer ;
• clés API ;
• chaînes de connexion ;
• secrets de test ;
• variables par environnement.

Le réflexe courant est de les mettre dans un .env, un script ou un fichier de configuration. Cela crée une surface facile à parcourir pour une extension compromise.

Le système d'environnements d'Apidog permet de déplacer ces valeurs hors des fichiers en texte clair du projet.

Utiliser des variables d'environnement au lieu de secrets en clair

Dans Apidog, vous pouvez stocker les identifiants sous forme de variables d'environnement.

Au lieu d'écrire :

Authorization: Bearer sk-proj-aB3dEf9hKlMnOpQrStUvWxYz1234567890

Vous référencez une variable :

Authorization: Bearer {{access_token}}

La requête garde la structure nécessaire, mais le secret littéral n'est pas dans un fichier .env à la racine du projet.

Utiliser les valeurs locales pour les secrets

Apidog distingue deux types de valeurs :

• valeur partagée ou initiale : synchronisée avec le projet et visible par l'équipe ;
• valeur locale ou actuelle : conservée sur votre machine et non téléchargée.

Pour les secrets comme les tokens, mots de passe et clés API, utilisez la valeur locale.

Effet pratique :

• l'équipe partage les noms des variables ;
• chaque développeur renseigne ses propres valeurs locales ;
• les secrets actifs ne circulent pas dans les données synchronisées ;
• aucun fichier partagé ne contient les vraies clés.

Exemple de variables :

base_url
access_token
payment_api_key
db_password

La structure est commune. Les valeurs sensibles restent locales.

Isoler les environnements

La gestion des environnements d'Apidog permet de définir des environnements distincts :

• Développement ;
• Staging ;
• Production.

Chaque environnement peut avoir :

• sa propre URL de base ;
• ses propres variables ;
• ses propres valeurs locales.

Exemple :

Variable	Développement	Staging	Production
base_url	API sandbox	API staging	API production
payment_api_key	clé test	clé staging	clé production
access_token	token local dev	token staging	token prod

Vous ne modifiez pas la requête pour changer d'environnement. Vous changez l'environnement actif.

Cela réduit les erreurs comme :

• envoyer une requête de test vers la production ;
• utiliser une clé de production dans un projet local ;
• copier une clé réelle dans un fichier .env.

Utiliser Vault Secret pour les équipes qui ont besoin d'une limite plus stricte

Pour les équipes qui veulent éviter que les secrets de production touchent le client API, le plan Enterprise d'Apidog ajoute une fonctionnalité Vault Secret.

Elle permet de récupérer des secrets depuis :

• HashiCorp Vault ;
• Azure Key Vault ;
• AWS Secrets Manager.

Apidog stocke uniquement le chemin du coffre-fort et les métadonnées. Les valeurs réelles sont extraites à la demande, chiffrées dans le client local et non partagées avec les coéquipiers via le projet.

C'est le bon modèle pour les secrets de production : ils restent dans un gestionnaire de secrets dédié.

Pour tester ce workflow, téléchargez Apidog, créez un projet, ouvrez la gestion des environnements et ajoutez vos identifiants comme variables avec des valeurs locales uniquement.

Important : déplacer les secrets vers Apidog réduit le nombre de secrets en clair dans le dépôt et l'espace de travail. Cela ne rend pas votre machine invulnérable. Continuez à auditer vos extensions, limiter les privilèges, utiliser des durées de vie courtes et faire pivoter les clés.

Checklist d'audit rapide pour votre dépôt

Avant de passer à autre chose, exécutez cet audit sur un projet réel.

1. Chercher les secrets évidents

grep -RInE "api[_-]?key|secret|token|password|private_key|access_key" .

Excluez les dossiers bruyants si nécessaire :

grep -RInE "api[_-]?key|secret|token|password|private_key|access_key" . \
  --exclude-dir=node_modules \
  --exclude-dir=.git \
  --exclude-dir=dist \
  --exclude-dir=build

2. Vérifier les fichiers suivis par Git

git ls-files | grep -E "\.env|secret|credentials|\.npmrc|\.pypirc|id_rsa"

3. Vérifier l'historique

git log --all --full-history --oneline -- .env
git log -p --all | grep -iE "api[_-]?key|secret|token|password"

4. Réagir correctement

Si vous trouvez un secret :

1. considérez-le comme exposé ;
2. faites pivoter la clé ;
3. supprimez le secret du dépôt et de l'historique ;
4. remplacez-le par une variable d'environnement locale ou un gestionnaire de secrets ;
5. ajoutez une règle de prévention dans votre CI si possible.

Conclusion

La violation de GitHub rappelle une réalité simple : les attaquants ciblent les machines de développeurs parce qu'elles contiennent souvent des outils de confiance, des fichiers de configuration et des secrets en texte clair.

Vous ne pouvez pas rendre chaque poste parfaitement sûr. Mais vous pouvez réduire fortement ce qu'un attaquant obtient si une extension IDE ou un dépôt est compromis.

Commencez par :

• rechercher les clés, tokens et mots de passe dans votre dépôt ;
• vérifier l'historique Git ;
• faire pivoter les secrets exposés ;
• supprimer les secrets des fichiers en clair ;
• séparer les environnements ;
• utiliser des clés courtes et limitées ;
• stocker les identifiants API dans des variables locales ou un coffre-fort.

Téléchargez Apidog et placez vos prochains identifiants API dans des variables d'environnement plutôt que dans un fichier .env en clair.

Pour continuer, consultez aussi nos articles sur les outils API auto-hébergés après la violation de GitHub et les outils de gestion des clés API.

FAQ

Une extension VS Code peut-elle vraiment lire mon fichier .env et mes clés API ?

Oui. Une extension VS Code s'exécute avec les permissions de fichier de votre compte utilisateur. Elle peut lire des fichiers comme .env, des fichiers de configuration ou ~/.aws/credentials. C'est un comportement normal pour de nombreuses extensions. Le risque vient des extensions malveillantes ou compromises qui abusent de cet accès.

Ajouter .env à .gitignore suffit-il à protéger les clés API ?

Non. .gitignore empêche seulement Git d'ajouter automatiquement certains fichiers non suivis. Il ne protège pas le fichier sur le disque et ne supprime pas les secrets déjà committés. Utilisez-le comme mesure d'hygiène, pas comme contrôle de sécurité.

Que faire si je trouve une clé API dans mon historique Git ?

Traitez-la comme compromise. Faites d'abord pivoter la clé. Ensuite, nettoyez l'historique avec un outil comme git filter-repo, coordonnez le push forcé avec l'équipe, puis déplacez la valeur active hors des fichiers en texte clair.

Comment Apidog réduit-il l'exposition des clés API ?

Apidog permet de stocker les identifiants sous forme de variables d'environnement et de les référencer dans les requêtes par nom, comme {{access_token}}. Les valeurs locales restent sur votre machine et ne sont pas synchronisées avec l'équipe. Cela réduit le nombre de secrets actifs présents dans les fichiers lisibles de l'espace de travail.

Apidog a-t-il aussi une extension VS Code ?

Oui. Apidog propose une extension VS Code et un serveur MCP. Le point n'est pas qu'un outil côté client serait immunisé contre les attaques de chaîne d'approvisionnement. Le point est de limiter les secrets en clair dans les fichiers du projet et de réduire l'impact si un outil local est compromis.

Quelle est la différence entre limitation de portée et rotation ?

La limitation de portée définit ce qu'une clé peut faire et où elle peut être utilisée. La rotation remplace régulièrement la valeur de la clé pour rendre l'ancienne inutilisable. La première réduit les dégâts. La seconde réduit la durée pendant laquelle une fuite reste exploitable.

À quelle fréquence faut-il faire pivoter les clés API ?

Utilisez un calendrier fixe. Une base raisonnable est mensuelle pour les clés de production à privilège élevé et trimestrielle pour les clés moins sensibles. Ajustez selon le risque, la conformité et la criticité du service.

Les clés API de production doivent-elles être sur un ordinateur portable de développeur ?

Idéalement, non. Les clés de production doivent rester dans un gestionnaire de secrets dédié et dans l'environnement d'exécution de production. Les développeurs devraient utiliser des identifiants de développement ou de staging limités à des données non-production.