Secret exposé : quand une clé privée devient lisible par tous

Un secret, c'est une clé qui donne un pouvoir : débiter une carte, envoyer des emails au nom de ton domaine, lire toute ta base, appeler un modèle d'IA facturé à l'usage. Tant qu'il reste sur un serveur, il fait son travail en silence. Dès qu'il apparaît ailleurs, quiconque le lit hérite du même pouvoir.

Les trois endroits où un secret s'échappe

Le code envoyé au navigateur. Tout ce que l'interface exécute est téléchargé par chaque visiteur, en clair. La documentation de Vite, l'outil de build utilisé par Lovable, Bolt et beaucoup d'autres, le dit sans détour : les variables préfixées VITE_ sont intégrées au code envoyé au client et ne doivent pas contenir d'informations sensibles comme des clés d'API. Next.js applique la même logique au préfixe NEXT_PUBLIC_.

Le dépôt Git. Un fichier .env versionné, une clé écrite en dur dans un fichier de configuration ou un script de test. Supprimer la ligne ne suffit pas : l'historique conserve chaque version. GitHub bloque par défaut l'envoi de nombreux types de secrets vers les dépôts publics, grâce à la push protection, mais ce filet ne couvre pas tous les formats ni tous les dépôts privés.

Les à-côtés. Une capture d'écran partagée dans un ticket, un journal d'erreurs qui affiche la configuration, un prompt collé dans un outil tiers, un fichier transmis à un freelance. Moins spectaculaires, ces fuites sont aussi plus difficiles à retracer.

Pourquoi c'est fréquent dans les apps construites avec l'IA

L'outil IA cherche à faire fonctionner la demande. Si tu demandes « envoie un email de bienvenue avec Resend » ou « ajoute un résumé par OpenAI », la voie la plus courte consiste à appeler le service directement depuis l'interface, avec la clé à portée de main. La fonctionnalité marche, la démo convainc, et la clé voyage avec chaque page.

Les plateformes ont progressé. Lovable propose un scan approfondi qui recherche notamment les secrets divulgués, et pousse les appels sensibles vers des fonctions serveur. Ces garde-fous sont précieux. Ils ne remplacent pas un inventaire complet, en particulier sur un projet qui a connu plusieurs outils, plusieurs exports ou plusieurs personnes.

Comment vérifier ton app

1. Cherche les préfixes connus dans le code du navigateur (outils de développement, onglet Sources) et dans le dépôt : sk_live_ et rk_live_ (Stripe), sb_secret_ ou service_role (Supabase), re_ (Resend), sk- (OpenAI et autres), AKIA (AWS)
2. Liste les variables VITE_ ou NEXT_PUBLIC_ et demande pour chacune : est-ce une valeur que n'importe quel visiteur peut connaître sans risque ?
3. Passe l'historique Git au crible avec un outil dédié comme gitleaks ou trufflehog, qui reconnaissent des centaines de formats
4. Vérifie le fichier .gitignore : .env, .env.local et *.local doivent y figurer
5. Regarde les journaux et les messages d'erreur affichés à l'utilisateur : ils ne doivent jamais contenir de configuration

Un exemple concret

Un outil de prise de notes construit avec v0 propose de résumer chaque note par IA. L'appel au modèle part directement du navigateur, avec la clé du fournisseur dans une variable NEXT_PUBLIC_. Personne ne s'en aperçoit pendant trois mois. Puis la facture mensuelle passe de 40 à plusieurs milliers d'euros : la clé a été extraite et sert à d'autres projets.

La correction comporte trois étapes : une nouvelle clé chez le fournisseur, un appel déplacé dans une fonction serveur qui vérifie que l'utilisateur est connecté, et un plafond de dépense configuré chez le fournisseur. L'ancienne clé est révoquée en dernier, une fois la nouvelle en place, pour éviter toute coupure.

Les erreurs les plus fréquentes

• Considérer qu'un dépôt privé protège les secrets : il est partagé avec chaque outil, chaque collaborateur et chaque intégration qui y a accès
• Supprimer la clé sans la remplacer, en laissant l'ancienne active
• Confondre clé publique et clé secrète chez le même fournisseur (Stripe pk_ et sk_, Supabase publishable et secret)
• Utiliser la même clé en test et en production, ce qui multiplie les endroits où elle circule
• Ne fixer aucun plafond de dépense ou de volume chez les fournisseurs facturés à l'usage

Ce qu'il faut retenir

Un secret exposé se corrige bien, à condition de le traiter dans l'ordre : nouvelle clé, déplacement côté serveur, révocation de l'ancienne, puis nettoyage. Ces étapes figurent dans la checklist avant de vrais utilisateurs. Le Scan de vibebusters cherche les secrets dans le code servi, le dépôt et son historique, et livre un plan de remplacement clé par clé, que l'Intervention peut exécuter pour toi.