Clés API et variables d'environnement dans un IDE web

La première règle est inconfortable mais simple : une application web statique ne peut pas garder un secret. Le navigateur télécharge HTML, CSS et JavaScript, puis les exécute sur la machine de l'utilisateur. N'importe qui peut ouvrir les DevTools, lire le panneau réseau, fouiller le bundle ou poser un point d'arrêt et inspecter une variable. Minifier le code, le découper en morceaux ou cacher une valeur dans un fichier de configuration change l'effort, pas le résultat. Un IDE web ajoute un sandbox pour exécuter le code du projet, mais l'interface de l'IDE s'exécute toujours sur la même origine et doit lire ce dont elle a besoin pour fonctionner. Le sandbox n'est pas un coffre pour les valeurs que l'interface elle-même doit utiliser. Le test utile est direct : si une valeur doit être disponible pour le code exécuté dans l'onglet, partez du principe que la personne qui utilise l'onglet peut la lire, et que tout script exécuté sur la même origine peut aussi la lire. Cela ne rend pas le développement dans le navigateur dangereux. Cela définit la frontière. Les identifiants publics peuvent y vivre ; les identifiants serveur non.

Sur un serveur Node.js, une variable d'environnement est lue à l'exécution depuis le processus. Dans une compilation Vite, Create React App, Next.js ou Astro, les variables d'environnement publiques fonctionnent différemment : le bundler remplace les références par des chaînes littérales pendant la compilation. Vite expose les variables préfixées par VITE_ via import.meta.env ; Create React App utilise REACT_APP_ ; Next.js utilise NEXT_PUBLIC_ ; Astro utilise PUBLIC_. Le préfixe est une convention de nommage, pas un contrôle de sécurité. Une fois la valeur intégrée, elle fait partie du JavaScript que chaque visiteur télécharge. Une variable sans préfixe public n'est normalement pas accessible au code client, ce qui explique pourquoi les valeurs réservées au serveur doivent être lues par un serveur ou une fonction serverless, et non par une page statique. Un fichier .env est une entrée de développement et de compilation, pas un coffre de secrets à l'exécution. Il est utile pour la configuration locale et pour garder des valeurs hors du contrôle de version, mais il ne rend pas une valeur privée après la compilation.

# Safe to expose: a public endpoint
VITE_API_URL=https://api.example.com

# Never expose: keep this on a server
STRIPE_SECRET_KEY=REPLACE_WITH_SERVER_SECRET

Certaines clés sont conçues pour être publiques. Une clé publiable Stripe identifie un compte et crée des jetons de paiement ; la clé secrète déplace réellement de l'argent et doit rester sur un serveur. Une clé anon Supabase n'est sûre que si les politiques de sécurité au niveau des lignes sont correctes. Une configuration web Firebase identifie un projet, mais ne donne pas d'accès administratif. Les clés de cartes et de mesure d'usage sont souvent limitées par domaine ou par API. Ces valeurs peuvent être envoyées au navigateur, mais elles méritent quand même des limites : origines autorisées, restrictions d'API, rôles à privilèges minimaux, quotas et alertes. La catégorie opposée est plus facile à énoncer. Les clés de rôle de service, les mots de passe de bases de données, les identifiants SMTP, les secrets de signature et les clés privées de fournisseurs d'IA ne doivent jamais figurer dans un bundle statique. Une clé de fournisseur qui appartient à l'application est particulièrement dangereuse : quiconque la trouve peut dépenser l'argent de l'application. Une clé qui appartient à l'utilisateur est un autre cas. Elle reste un identifiant bearer, mais c'est le sien, et l'objectif est de la garder dans son navigateur plutôt que dans le projet ou le dépôt.

Le panneau IA de GB Coder fonctionne en bring-your-own-key. Le gestionnaire de clés conserve les clés de fournisseur en mémoire par défaut. Il ne les écrit pas dans localStorage. L'utilisateur peut choisir explicitement une persistance dans sessionStorage, ce qui limite la valeur à l'onglet courant et l'efface normalement à la fermeture de l'onglet. La clé est retirée de la mémoire et du stockage de session lorsque l'utilisateur l'efface. Le gestionnaire lie aussi chaque clé à une origine de point de terminaison autorisée, et une porte de sortie vérifie qu'un identifiant n'est pas envoyé vers une destination non approuvée. Les erreurs des fournisseurs passent par une couche de rédaction qui supprime les motifs de clés et les clés actives avant que le message n'atteigne l'interface ou un journal. Les métadonnées des fournisseurs personnalisés sont stockées dans localStorage, mais les en-têtes marqués comme secrets sont effacés avant la persistance et doivent être saisis à nouveau. Les requêtes vont directement du navigateur au point de terminaison du fournisseur ; GB Coder ne fait pas transiter la clé par un serveur LadeStack. Ces mesures réduisent la persistance accidentelle et les fuites entre origines. Elles ne changent pas la règle de base : tout script capable de s'exécuter sur la même origine peut lire ce que la page peut lire. Utilisez un profil propre pour les travaux sensibles et n'installez pas d'extensions non fiables.

Gardez les secrets hors de l'arborescence du projet. Ajoutez .env et ses variantes locales à .gitignore, et validez un .env.example avec des noms de remplacement. Si un projet utilise Vite, rappelez-vous que chaque variable VITE_ est intégrée au bundle de production. Une valeur pratique en développement local devient publique dès qu'elle est utilisée dans une compilation de production. Avant de déployer, inspectez les ressources générées à la recherche de motifs de clés et traitez toute correspondance comme un incident, pas comme un avertissement. La détection de secrets et la protection push de GitHub peuvent repérer certains formats de jetons connus, mais elles constituent un filet de sécurité, pas un substitut au fait de garder les valeurs hors du dépôt. L'export ZIP d'un IDE web inclut les fichiers du projet. Si un fichier .env se trouve dans le projet, il voyage avec la sauvegarde. Une sauvegarde n'est pas un coffre chiffré. Stockez les exports dans un endroit privé et supprimez les anciennes copies lorsqu'elles ne sont plus utiles. Il en va de même pour les captures d'écran, les rapports de bogues et les messages de chat : une clé collée dans l'un d'eux a déjà quitté le navigateur.

# .gitignore
.env
.env.local
.env.*.local

Les jetons d'accès personnels GitHub et les jetons de déploiement sont plus puissants qu'ils n'en ont l'air. Un jeton classique avec les portées repository et workflow peut lire du code privé, modifier des fichiers et déclencher des releases. Préférez les jetons fine-grained limités à un seul dépôt, avec une liste explicite de permissions et une date d'expiration. N'accordez à un jeton que les permissions nécessaires à la tâche : lecture et écriture des contenus pour une synchronisation, pas administration ni facturation. Créez des jetons distincts pour des appareils ou des usages distincts et révoquez-les une fois le travail terminé. Les jetons de déploiement Vercel ou Netlify peuvent publier, remplacer ou supprimer des projets. Si le fournisseur permet une portée par projet ou par équipe, utilisez-la ; s'il permet une expiration, définissez-la. Ne collez le jeton dans le panneau de déploiement que lorsque c'est nécessaire et ne l'enregistrez pas dans un fichier du projet. En CI, utilisez les secrets du dépôt ou de l'organisation plutôt qu'un .env validé, et rappelez-vous que les pull requests issues de forks ne reçoivent normalement pas de secrets. Un jeton photographié, partagé dans un chat ou validé dans un dépôt public doit être considéré comme compromis, même s'il a été supprimé une seconde plus tard.

Une clé de fournisseur d'IA est un identifiant bearer avec une facture attachée. Quiconque la possède peut envoyer des requêtes, consommer du quota et générer des frais. Utilisez une clé limitée à un projet, fixez une limite de dépenses si le fournisseur le permet, et utilisez une clé distincte pour les expérimentations plutôt que la clé maîtresse de l'organisation. Surveillez l'usage régulièrement, surtout après avoir partagé un appareil ou installé une nouvelle extension. Les fournisseurs locaux comme Ollama, LM Studio et vLLM n'ont pas besoin de clé cloud, mais leurs points de terminaison restent des services sur la machine. N'exposez pas un point de terminaison local à l'internet public juste pour faire fonctionner une démo. Si un fournisseur personnalisé pointe vers un proxy, le proxy peut voir la clé ; n'utilisez qu'un proxy que vous contrôlez et comprenez. L'injection de prompts est un risque connexe : un fichier, une page web ou un message d'erreur collé peut contenir des instructions destinées à l'assistant. Gardez les secrets hors des prompts et hors des fichiers que l'assistant est autorisé à lire. Si une clé apparaît dans une conversation, faites-la tourner.

Un ordinateur partagé ou de laboratoire mérite une routine différente. Utilisez un profil de navigateur privé, ne choisissez pas la persistance de session et fermez l'onglet lorsque vous avez terminé. Si le navigateur propose d'enregistrer la clé, refusez. Effacez le stockage du site si vous pensez qu'il a été conservé. Les extensions de navigateur font partie de la frontière : une extension dotée de larges permissions d'hôte peut souvent lire le contenu ou le stockage de la page, et une mise à jour malveillante peut arriver après l'installation. Utilisez un profil minimal pour les travaux impliquant des identifiants. Le cross-site scripting est le risque web classique dans ce contexte. Si un attaquant peut exécuter un script sur l'origine de l'IDE, ce script peut lire localStorage et sessionStorage et envoyer des requêtes tant que la page est ouverte. Gardez les dépendances à jour, évitez les scripts tiers non fiables et envisagez une politique de sécurité du contenu sur le site déployé. Les gestionnaires de presse-papiers et les outils de partage d'écran voient aussi ce que vous copiez et affichez. Videz le presse-papiers après avoir déplacé une clé et suspendez le partage avant d'ouvrir un panneau de configuration de fournisseur.

La rotation est la seule réponse fiable à une clé compromise. Révoquer d'abord est important : si l'ancienne clé reste valide pendant que la nouvelle est préparée, l'exposition continue. Créez la nouvelle clé avec la portée la plus étroite possible, mettez à jour l'application ou les réglages du navigateur, redéployez si la valeur faisait partie d'une compilation, puis vérifiez que l'ancienne clé est rejetée. Consultez ensuite l'usage et les journaux d'audit du fournisseur pour repérer une activité inattendue. Si la clé a été validée dans Git, supprimer le fichier ne suffit pas ; la valeur reste dans l'historique. Faites d'abord tourner la clé, puis réécrivez l'historique avec un outil comme git filter-repo ou BFG, forcez le push avec l'accord de l'équipe et demandez aux collaborateurs de recloner. Les plateformes d'hébergement peuvent mettre en cache d'anciens builds ; assurez-vous que l'ancienne valeur ne peut pas être servie depuis un bundle obsolète. Si la clé a été collée dans un chat IA, un ticket de support ou une capture d'écran, supposez qu'elle a été conservée et faites-la tourner. Enfin, consignez ce qui s'est passé, ajoutez un contrôle qui l'aurait détecté et raccourcissez la durée de vie de la clé suivante.

Utilisez cette séquence avant qu'un projet ne quitte le navigateur. Premièrement, classez chaque valeur : identifiant public, identifiant utilisateur ou secret serveur. Deuxièmement, gardez les secrets serveur hors du bundle statique et placez-les derrière une fonction serverless ou une API. Troisièmement, n'exposez que les valeurs qui ont besoin du préfixe public et inspectez les ressources compilées avant le déploiement. Quatrièmement, gardez les fichiers .env hors de Git, validez un .env.example et activez la détection de secrets. Cinquièmement, créez des jetons à portée limitée et expirants pour GitHub et l'hébergement, un par usage. Sixièmement, dans GB Coder, laissez les clés en mémoire sauf si vous êtes sur un appareil de confiance, et n'activez la persistance de session que si vous comprenez le compromis. Septièmement, ne collez jamais une clé dans un prompt, un ticket, une capture d'écran ou un fichier du projet. Huitièmement, faites tourner la clé au moindre doute et révoquez avant de remplacer. Neuvièmement, utilisez un profil de navigateur propre sur les machines partagées. Dixièmement, écrivez le plan de fuite avant d'en avoir besoin. Un IDE web peut gérer des identifiants de manière responsable s'il traite le navigateur comme un client public et non comme un coffre privé.