Une clé secrète Stripe dans votre frontend peut déplacer de l’argent

Ouvrez votre appli en production dans un navigateur, affichez le code source de la page et cherchez-y sk_live_. Si une longue chaîne remonte, une clé secrète Stripe est exposée dans votre frontend, et tous les visiteurs que vous avez jamais eus auraient pu la copier.

Voici ce que les conseils généraux sur les clés d’API se trompent : Stripe vous donne deux clés actives, elles se ressemblent presque trait pour trait, et l’une des deux est censée se trouver dans votre appli. La clé qui commence par pk_live_ y a sa place. La clé qui commence par sk_live_ dispose, selon les mots mêmes de Stripe, de droits illimités sur toutes les API. Elles diffèrent d’un caractère au milieu d’une longue chaîne, et c’est l’essentiel de la raison pour laquelle cela continue d’arriver.

Entre le 12 et le 14 août 2026, nous avons passé neuf contrôles externes sur 30 998 applis en production construites avec Lovable, Bolt, v0, Replit et Base44. Trois d’entre elles livraient une clé secrète Stripe active, et deux autres une clé restreinte, ce qui en fait l’un des constats les plus rares du balayage ; ces mêmes neuf contrôles ont trouvé une clé d’API Google dans 1 142 applis. Les trois clés secrètes sont ressorties avec la note D, parce qu’un seul constat critique plafonne la note à ce niveau quoi que l’appli ait fait de bien par ailleurs. Les chiffres complets sont dans notre rapport de scan.

Une clé secrète Stripe exposée dans votre frontend, est-ce un problème ?

Oui, si la chaîne commence par sk_live_. Non, si elle commence par pk_live_.

Stripe émet deux clés actives parce que les deux moitiés d’un paiement se déroulent à deux endroits différents. Imaginez le comptoir d’un magasin. Le terminal de paiement fait face au client et il est vissé bien en vue, et le pire qu’un inconnu puisse en faire, c’est vous payer. La caisse derrière le comptoir est un tout autre objet. Elle s’ouvre, elle contient la recette du jour, et le tiroir en dessous contient une fiche par client avec son adresse écrite dessus.

pk_live_, c’est le terminal de paiement. Son travail consiste à construire un formulaire de paiement dans le navigateur de quelqu’un d’autre, et la documentation de Stripe dit que les clés publiables peuvent sans risque être exposées dans le code frontend.

sk_live_, c’est la clé de la caisse. Stripe décrit les clés secrètes comme ayant des droits illimités sur toutes les API, ce qui est la même phrase lue de l’autre côté : il n’y a rien dans votre compte qu’elle n’atteigne pas.

Votre appli a besoin du terminal dans le navigateur ne serait-ce que pour encaisser. De la clé de la caisse, elle ne devrait jamais avoir besoin.

pk_live_ et sk_live_ : comment les distinguer

Lisez le deuxième caractère du préfixe. C’est tout le test.

Le milieu du préfixe est la deuxième chose à lire. _test_ n’atteint rien au-delà de votre bac à sable, une clé de test fuitée ne vous coûte donc pas d’argent ; elle publie tout de même la façon dont votre intégration est construite, et la consigne de Stripe est de traiter comme compromise toute clé secrète ou restreinte vue là où elle ne devait pas être. Les comptes plus récents peuvent aussi porter une clé d’organisation commençant par sk_org_, qui opère sur plusieurs comptes Stripe à la fois. Elle suit la même règle, et une fuite y porte plus loin qu’un seul compte.

Ce que quelqu’un peut faire avec une clé secrète Stripe fuitée

Tout ce que vous pouvez faire dans votre propre tableau de bord sans mot de passe.

Pas « obtenir un accès non autorisé ». Concrètement, avec rien de plus que la chaîne et un terminal : lire votre liste complète de clients, avec les noms, les adresses e-mail, les adresses de facturation et les quatre derniers chiffres de chaque carte. Lire tous les paiements que vous avez encaissés, et ce que chaque client a payé. Émettre des remboursements. Créer des débits et des liens de paiement en votre nom. Résilier des abonnements.

Il y a ensuite l’usage qui n’a rien à voir avec vous. Votre compte devient un endroit où pratiquer le card testing, le terme de Stripe lui-même pour un fraudeur qui fait passer des numéros de carte volés par l’intégration de n’importe qui afin de trouver ceux qui fonctionnent encore. Les cartes appartiennent à d’autres. Les refus, les litiges et les explications vous appartiennent.

Ce qu’ils ne peuvent généralement pas faire, c’est se payer eux-mêmes. Un remboursement retourne sur la carte qui a fait le paiement d’origine, et un virement part vers le compte bancaire enregistré, qui est le vôtre. Cela a l’air d’une bonne nouvelle et n’en est pas une : le dommage arrive sous la forme de votre argent qui part, des fiches de vos clients qui sont copiées et de votre compte utilisé pour la fraude d’un autre, plutôt que sous la forme d’un virement que vous pourriez montrer du doigt et poursuivre.

Rien de tout cela n’exige un attaquant sophistiqué. La documentation de Stripe dit elle-même que des acteurs frauduleux balaient en continu les bases de code publiques à la recherche de clés exposées, et ces scanners n’ont pas besoin de savoir qui vous êtes pour trouver la vôtre.

Comment renouveler une clé secrète Stripe sans casser les paiements

Créez d’abord le remplacement, mettez-le en service, puis faites expirer l’ancienne. Dans cet ordre.

1. Dans le tableau de bord Stripe, créez une nouvelle clé secrète. Laissez l’ancienne tranquille pour l’instant ; les deux fonctionnent en même temps, et c’est ce recouvrement qui garde votre checkout en marche.
2. Mettez la nouvelle clé là où vivait l’ancienne, c’est-à-dire sur un serveur, dans une Edge Function ou dans une route serverless. Jamais dans l’appli que le navigateur télécharge.
3. Déployez, puis encaissez un vrai paiement. Un débit qui aboutit est la seule preuve que la nouvelle clé est correctement branchée.
4. Faites expirer l’ancienne clé. Stripe le décrit ainsi : faire expirer une clé secrète ou restreinte l’empêche de passer le moindre appel d’API supplémentaire.
5. Lisez votre historique de paiements sur la période où la clé était exposée, et vos e-mails Stripe pour tout ce que vous n’avez pas fait.

Si la clé est déjà dehors et que vous préférez perdre quelques paiements plutôt que de la laisser active une heure de plus, faites l’inverse. Renouveler une clé la bloque immédiatement et en génère une nouvelle, et Stripe précise que les endpoints de webhook créés avec l’ancienne clé restent actifs, votre traitement d’événements survit donc à l’urgence.

Il reste une étape, et c’est celle que la plupart des gens font en premier : supprimer la clé de votre code. Faites-le, en sachant ce que cela produit. Vos visiteurs ont déjà téléchargé le fichier qui la portait, ce fichier est dans des caches de navigateur que vous ne contrôlez pas, et l’ancienne valeur figure toujours dans votre historique de versions. Faire expirer la clé chez Stripe est ce qui ferme la porte. Retirer la ligne vous empêche de l’expédier à nouveau.

Les clés publiables, soit dit en passant, ne peuvent pas expirer du tout. Stripe n’a jamais construit ce contrôle, parce que cette clé n’a jamais été censée rester privée.

Ce qu’est une clé restreinte Stripe, et quand elle est la bonne réponse

Une clé taillée pour une tâche plutôt que pour toutes.

Une clé restreinte commence par rk_live_ et ne porte que les droits que vous cochez à sa création. Une clé autorisée à lire des factures ne peut pas émettre de remboursement. Une clé autorisée à créer des débits ne peut pas lire votre liste de clients. Stripe recommande de passer des clés secrètes aux clés restreintes exactement pour cette raison, et c’est un bon conseil au sujet du code qui tourne sur votre serveur.

Ce n’est pas un moyen de rendre acceptable une clé dans le navigateur. Deux des 30 998 applis de notre balayage livraient une clé restreinte dans le frontend, et les deux sont ressorties avec la note C. Notre scan classe une clé restreinte en constat élevé là où une clé secrète est un constat critique, et un seul constat élevé plafonne la note à C. Celui qui trouve cette clé obtient encore chacun des droits que vous avez cochés, depuis n’importe où.

Là où une clé restreinte gagne sa place, c’est dans le cas intermédiaire inconfortable, et les applis vibe-codées en produisent beaucoup. Un outil d’automatisation qui doit lire vos virements. Un script de reporting que quelqu’un vous a écrit sur Fiverr. Une Edge Function qui ne crée jamais qu’un seul type de débit. Chacun tourne sur un serveur et chacun a besoin d’une fraction de votre compte, chacun reçoit donc sa propre clé avec cette fraction cochée, et le jour où l’une fuite, vous révoquez une clé au lieu de recâbler toute votre intégration.

Comment vérifier ce que votre appli livre réellement

Commencez à la main, cela ne coûte rien et ne demande aucune installation. Ouvrez votre site en production, affichez le code source de la page et cherchez-y sk_live_, puis rk_live_, puis pk_live_. Trouver la troisième et pas les deux premières est le résultat que vous voulez.

Ce qu’une recherche dans le code source manque, c’est le JavaScript que la page charge ensuite, et sur une appli construite avec Lovable, Bolt ou Replit, c’est presque tout. Notre scanner gratuit ouvre votre appli dans un vrai navigateur, attend l’arrivée des bundles et lit ceux-là. Il classe ce qu’il trouve au lieu de faire correspondre des chaînes en forme de clé, si bien que pk_live_ revient marquée comme correcte et sk_live_ revient en constat critique, et les deux ne se retrouvent jamais dans la même pile.

La note, le score et les décomptes s’affichent à l’écran en une vingtaine de secondes, sans compte. Donnez une adresse e-mail et la liste détaillée arrive avec, accompagnée d’un correctif écrit pour le builder que vous avez utilisé et que vous pouvez coller tel quel.

Trois choses que le scan ne fera pas, et ce sont les raisons pour lesquelles on peut le pointer sans crainte sur une appli en production qui encaisse vraiment : il ne se connecte jamais, il n’écrit jamais rien, et il ne conserve jamais une clé qu’il trouve. Un secret exposé est stocké sous forme d’indice masqué de la forme sk_live_…a1b2, et la vraie valeur est jetée. Scannez votre appli, ou lisez d’abord ce que regarde chacun des neuf contrôles.

Que faire maintenant

Une clé Stripe arrive en général tard. L’appli sort, elle tourne un moment, et puis un jour vous ajoutez le checkout, et c’est ce déploiement-là qui met pour la première fois un identifiant de paiement dans le bundle. Le scan que vous avez lancé au lancement était la photographie d’une appli qui ne pouvait pas encore encaisser.

Reeve Monitor est fait pour cet écart. Il repasse les neuf contrôles toutes les heures sur trois applis au plus, surveille la disponibilité toutes les 60 secondes, vous prévient le jour où un résultat change au lieu d’attendre que vous regardiez, et envoie un rapport mensuel en langage clair. Une clé qui atteint le bundle avec un déploiement du jeudi se retrouve dans le scan de l’heure qui suit. C’est €12 par mois au tarif public, avec sept jours gratuits avant tout prélèvement, et la page de tarifs est parfois en dessous du chiffre indiqué ici, jamais au-dessus.

Si vous préférez avancer par liste, la checklist de sécurité en 10 minutes couvre ce point ainsi que les autres choses à refermer dans une appli fraîchement lancée. Pour la question plus large de savoir quelles clés ont leur place dans un navigateur, nous avons un guide pour distinguer les clés publiables des clés secrètes, la même question pour une clé OpenAI, et un recensement de ce que 30 998 applis livraient vraiment.