La clé secrète Stripe dans le bundle frontend : 4 mois d'exposition silencieuse

La place de marché fonctionnait depuis huit mois. Deux cofondateurs, sans aucune expérience en sécurité, l'avaient construite sur Bubble.io avec Stripe Connect pour les paiements. Elle avait traité plus de 40 000 $ de transactions, comptait 1 500 utilisateurs enregistrés et connaissait une croissance constante grâce au bouche-à-oreille.

Douze minutes après le début du scan Penetrify, une découverte Critique est apparue : la clé secrète de l'API Stripe était intégrée dans un fichier JavaScript côté client, servi au navigateur de chaque visiteur. Elle était là depuis le lancement. Quatre mois d'accès complet en lecture/écriture à l'intégralité de leur compte Stripe, disponible pour quiconque ouvrait les DevTools.

Ceci est l'histoire de la façon dont une entreprise de 40 000 $ a failli devenir un exemple à ne pas suivre.

La clé API Stripe que vous ne devriez jamais exposer

Stripe émet deux types de clés API : les clés publiables et les clés secrètes.

La clé publiable (pk_live_...) est conçue pour être utilisée dans le code frontend. Elle ne peut effectuer que des opérations limitées — créer des jetons de méthode de paiement, confirmer des paiements — et ne peut pas accéder aux données de compte sensibles. Il est sûr de l'exposer dans le JavaScript côté client.

La clé secrète (sk_live_...) est une tout autre affaire. Avec une clé secrète Stripe, vous pouvez :

• Lister tous les clients, méthodes de paiement et abonnements
• Lire les empreintes complètes des cartes et les adresses de facturation de tous les clients
• Émettre des remboursements arbitraires sur toute transaction
• Créer des prélèvements sur toute méthode de paiement enregistrée
• Modifier ou supprimer les calendriers de paiement et les coordonnées bancaires
• Accéder à tous les Connected Accounts (dans ce cas, tous les comptes de paiement des vendeurs sur la place de marché)
• Récupérer les coordonnées bancaires de chaque vendeur qui s'était inscrit via Stripe Connect

La clé secrète Stripe est la clé maîtresse de toute votre infrastructure de paiement. Elle ne doit se trouver que dans le code côté serveur, dans des variables d'environnement qui ne sont jamais envoyées au navigateur.

Comment elle s'est retrouvée dans le bundle

Bubble.io est une plateforme no-code qui permet de créer des applications web full-stack sans écrire de code. Elle dispose d'un système de workflow intégré pour la logique côté serveur et d'un connecteur API pour les services externes. Pour une équipe de deux personnes sans expérience en ingénierie, c'est un moyen légitime de lancer rapidement un produit réel.

La clé secrète Stripe s'est retrouvée dans le frontend pour une raison familière à quiconque a développé sur une plateforme no-code sous la pression du temps : cela fonctionnait.

Pendant le développement, l'équipe devait effectuer des appels API Stripe à partir des workflows Bubble. Ils ont ajouté la clé secrète à la configuration du connecteur API. À un certain moment de la configuration — qu'il s'agisse d'une mauvaise compréhension de l'exécution côté client vs. côté serveur, ou d'un détail de configuration Bubble qui n'était pas évident — la clé a fini par être incluse dans la charge utile JavaScript envoyée au navigateur. Les flux de paiement fonctionnaient. Les transactions étaient traitées correctement. Il n'y a eu aucune erreur, aucun avertissement, aucun symptôme évident.

La plateforme de Bubble gère par défaut une grande partie de l'exécution côté serveur correctement, mais la frontière entre ce qui s'exécute dans le navigateur et ce qui s'exécute sur les serveurs de Bubble n'est pas toujours visuellement évidente dans le constructeur no-code. C'est un risque bien documenté dans la communauté des développeurs Bubble, mais il est facile de le manquer lorsque l'on se concentre sur le fonctionnement du produit plutôt que sur l'audit des données que votre application envoie au client.

Ce que l'exposition signifiait réellement

Soyons précis sur ce qui était en jeu pendant ces quatre mois.

Quiconque visitait la place de marché pouvait ouvrir les DevTools de Chrome, naviguer vers l'onglet Sources ou Network, rechercher sk_live_ dans les fichiers JavaScript et trouver la clé. Cela ne nécessite aucun outil de piratage, aucune connaissance particulière et aucune vulnérabilité au-delà de la capacité de faire un clic droit et d'inspecter une page web.

Avec cette clé, ils auraient pu :

• Vider le solde Stripe de l'entreprise en émettant des remboursements sur des transactions terminées, annulant ainsi des revenus déjà acquis
• Énumérer tous les enregistrements clients, y compris les noms, adresses e-mail, détails partiels de carte et adresses de facturation — une violation de données à signaler en vertu du RGPD et de diverses lois américaines sur la protection de la vie privée des États
• Accéder aux coordonnées bancaires des vendeurs pour chaque vendeur ayant connecté son compte de paiement via Stripe Connect — noms, numéros de compte, numéros d'acheminement
• Modifier les calendriers de paiement pour rediriger les paiements des vendeurs vers des comptes contrôlés par l'attaquant
• Créer des débits frauduleux sur toute méthode de paiement client enregistrée, dans la limite des plafonds de Stripe pour le compte

N'importe lequel de ces scénarios aurait mis fin à l'entreprise. Combinés, ils représentent le type de violation catastrophique qui fait l'objet de discussions lors des conférences sur la sécurité.

La clé Stripe avait été exposée pendant 4 mois. Pendant cette période, environ 8 000 personnes avaient visité la place de marché. N'importe laquelle d'entre elles aurait pu la trouver.

Les autres découvertes

La clé Stripe était la découverte la plus grave, mais l'analyse a révélé quatre problèmes supplémentaires :

MOYEN — Règles de confidentialité Bubble mal configurées

Les règles de confidentialité de Bubble contrôlent quels champs de base de données sont visibles par les différents rôles d'utilisateur. Les enregistrements de profil vendeur — qui incluaient les coordonnées bancaires saisies lors de l'intégration à Stripe Connect — étaient visibles par tout utilisateur authentifié via l'API de données de Bubble. Même sans la clé Stripe, tout acheteur connecté aurait pu interroger les informations financières des vendeurs.

MOYEN — Énumération de comptes via la réinitialisation de mot de passe

Le processus de réinitialisation de mot de passe renvoyait des réponses différentes pour les adresses e-mail enregistrées et non enregistrées. Une demande pour une adresse e-mail enregistrée renvoyait "Vérifiez votre boîte de réception" ; une demande pour une adresse e-mail non enregistrée renvoyait "Aucun compte trouvé". Cela permet à un attaquant de construire une liste des adresses e-mail ayant des comptes sur la plateforme — utile pour le phishing ciblé ou le credential stuffing.

MOYEN — Aucune Content Security Policy

L'application ne renvoyait aucun en-tête Content-Security-Policy. La fonctionnalité de recherche reflétait les entrées fournies par l'utilisateur sans encodage dans certains contextes, rendant possible le XSS réfléchi. Sans CSP, une charge utile XSS pourrait exfiltrer des jetons de session, effectuer des appels API authentifiés au nom de la victime, ou injecter des scripts malveillants dans la page pour d'autres visiteurs.

FAIBLE — Caractère générique CORS

L'API renvoyait Access-Control-Allow-Origin: *, permettant à n'importe quel site web d'effectuer des requêtes cross-origin vers les points d'extrémité de l'API et de lire les réponses. Pour les points d'extrémité renvoyant des données sensibles, cela permet l'exfiltration de données cross-site depuis une page malveillante visitée par la victime.

La réponse : Immédiate et efficace

Les fondateurs ont agi dans l'heure suivant la réception du rapport.

La première étape a été de renouveler la clé Stripe compromise. Dans le tableau de bord Stripe, sous Développeurs → Clés API, la clé secrète en direct peut être renouvelée — générant une nouvelle clé et invalidant immédiatement l'ancienne. Cela a pris environ deux minutes. À partir de ce moment, quiconque avait extrait la clé exposée ne pouvait plus l'utiliser.

La deuxième étape a été d'auditer les journaux d'événements de Stripe pour détecter toute activité non autorisée. Le tableau de bord de Stripe fournit un journal complet de chaque appel API effectué avec vos clés, y compris l'adresse IP et l'horodatage de chaque requête. Les fondateurs ont examiné le journal d'événements des quatre mois précédents à la recherche d'appels anormaux — remboursements qu'ils n'avaient pas émis, clients qu'ils n'avaient pas créés, modifications de paiement qu'ils n'avaient pas effectuées. Ils n'en ont trouvé aucune. La clé avait été exposée mais — pour autant qu'on puisse le déterminer — n'avait pas été activement exploitée.

La troisième étape consistait à corriger la configuration Bubble. En collaboration avec un développeur Bubble qu'ils ont engagé pour quelques heures, ils ont déplacé tous les appels d'API Stripe vers les workflows backend côté serveur de Bubble, où les clés d'API ne sont pas transmises au navigateur. Les règles de confidentialité de Bubble ont également été corrigées pour restreindre les données financières des vendeurs au seul compte vendeur concerné.

Comment détecter cela dans votre propre application

Si vous utilisez une application Bubble, Webflow ou toute autre application sans code qui s'intègre à Stripe, voici comment vérifier si vous êtes concerné par ce problème :

1. Ouvrez votre application dans une fenêtre de navigation privée.
2. Ouvrez les Chrome DevTools (F12) → onglet Réseau.
3. Rechargez la page.
4. Dans l'onglet Réseau, recherchez les fichiers JavaScript. Pour chacun d'eux, cliquez dessus et recherchez (Ctrl+F) sk_live_.
5. Vérifiez également l'onglet Sources. Utilisez Ctrl+Maj+F pour rechercher sk_live_ dans tous les scripts chargés.

Si vous trouvez votre clé secrète Stripe dans l'un de ces fichiers, révoquez-la immédiatement avant de faire quoi que ce soit d'autre, puis enquêtez sur la manière dont elle s'y est retrouvée.

Cette même vérification s'applique à toute autre clé d'API sensible : OpenAI, Twilio, SendGrid, AWS, Mailchimp. Toute clé avec un accès en écriture ou un accès à des données sensibles que vous trouvez dans le JavaScript côté client doit être considérée comme compromise et révoquée immédiatement.

Pourquoi ce schéma persiste-t-il ?

L'exposition des clés secrètes dans les bundles frontend n'est pas une nouvelle classe de vulnérabilité. C'est un risque connu et bien documenté depuis que les applications web utilisent des API tierces. Alors, pourquoi cela continue-t-il d'arriver ?

La réponse est que l'expérience de développement le rend facile. Les plateformes sans code et les frameworks JavaScript modernes estompent la frontière entre le client et le serveur d'une manière qui n'existait pas dans les modèles de développement web précédents. Les variables d'environnement préfixées par NEXT_PUBLIC_ sont intentionnellement envoyées au navigateur ; celles sans préfixe ne le sont pas. Le contexte d'exécution de Bubble dépend du type de workflow que vous utilisez. Les configurations de bundle Vite et webpack déterminent ce qui se retrouve dans le navigateur.

Ces limites sont documentées mais non appliquées au niveau des outils. Il n'y a pas d'erreur au moment de la compilation lorsque vous exposez accidentellement une clé secrète. L'application fonctionne correctement. L'exposition est silencieuse, indéfinie et s'accroît chaque jour où la clé reste valide.

La seule défense fiable est de la rechercher explicitement — et de la révoquer rapidement lorsque vous la trouvez.