Faire tourner une clé service_role Supabase qui a fuité

Quelqu'un vous a dit que votre clé service_role Supabase se trouve dans votre application, là où n'importe qui peut la lire. Avant de changer quoi que ce soit, assurez-vous que c'est bien cette clé qu'on a trouvée : notre scan gratuit lit votre site en production comme le lirait un inconnu et vous dit quelle clé Supabase il y voit réellement. Sans compte et sans rien installer.

Le conseil qui suit une trouvaille pareille tient presque toujours en un mot : remplacez-la. Puis vous cherchez comment faire, et les sources se contredisent. La documentation de Supabase ouvre son guide de rotation en vous disant de corriger la cause de la fuite avant de commencer. Une demi-douzaine de guides tiers vous disent de remplacer la clé immédiatement et de poser les questions après.

Voici la partie qu'aucun des deux n'écrit : les deux ont raison, dans des situations différentes, et la question qui les sépare est celle de l'endroit où la clé a fuité.

Une chose à poser d'abord. Supprimer la clé de votre code retire votre propre copie du trousseau. La remplacer change la serrure. Seul le second geste atteint les copies que d'autres possèdent déjà.

Est-ce vraiment la clé service_role ?

Sur un projet récent, ce sont les premiers caractères qui répondent. sb_secret_ au début, c'est la clé secrète. sb_publishable_, c'est celle qui doit se trouver dans votre application, et l'y trouver n'est pas une trouvaille du tout.

Assurez-vous-en avant toute manœuvre lourde, car la clé qu'on trouve dans une application faite en vibe coding est en général celle qui a sa place là.

Les anciens projets délivrent une autre paire, anon et service_role, et les deux se ressemblent énormément : même format, même longueur, aucun préfixe à lire. La section centrale d'une de ces clés n'est pas chiffrée du tout. Elle se décode en quelques lignes de texte, et l'une d'elles indique le rôle. Quelles clés d'API sont sûres dans votre frontend détaille les deux vérifications.

La raison d'en avoir le cœur net, c'est que le cas est plus rare que les avertissements ne le laissent croire. Nous avons scanné 30 998 applications en vibe coding en août 2026 et trouvé une clé service_role publiée dans 3 d'entre elles. Une clé d'API Google, généralement inoffensive et souvent restreinte à un domaine, est apparue dans 1 142. Le décompte complet est ici.

Remplacer d'abord, ou colmater la fuite d'abord ?

Cela dépend de si la clé est déjà publique, et la frontière entre les deux cas est nette.

Si la clé se trouve dans le JavaScript que vos visiteurs téléchargent, elle est publique maintenant. Tous ceux qui ont chargé votre site pendant qu'elle était active en ont une copie, et tous les robots qui cherchaient exactement cette chaîne aussi. Rien de ce que vous changez dans votre code n'atteint ces copies. Remplacez d'abord, corrigez la source ensuite.

Si elle n'a atteint qu'un dépôt privé, un fichier de journal, une variable de CI ou une conversation, l'exposition est bornée. Si vous remplacez la clé d'abord ici, vous le ferez deux fois, parce que le déploiement suivant ressort l'ancienne valeur de ce qui la produisait et que votre nouvelle clé suit l'ancienne. Colmatez la source, puis remplacez.

Le guide de Supabase est écrit pour le second cas. Les guides pressés sont écrits pour le premier. Si vous lisez ceci parce qu'un scanner a trouvé la clé sur votre URL en production, vous êtes dans le premier cas.

Comment remplacer une clé secrète Supabase

Si votre projet dispose de clés sb_secret_, tout se passe dans le tableau de bord et sans interruption de service.

Un projet peut détenir plusieurs clés secrètes à la fois, chacune avec son nom, et c'est ce qui rend l'opération sûre : vous ajoutez la nouvelle avant de retirer l'ancienne, donc rien n'est cassé entre les deux.

1. Ouvrez votre projet, allez dans Settings → API Keys et créez une nouvelle clé secrète.
2. Mettez-la partout où l'ancienne servait, ce qui devrait toujours être sur un serveur : edge functions, webhooks, tâches planifiées, un backend à vous. Où vivent ces valeurs si vous n'avez jamais ouvert cette page.
3. Déployez, puis parcourez les parties de votre application qui lisent et écrivent des données. Une mauvaise clé secrète échoue bruyamment et immédiatement, et c'est le bon cas de figure.
4. Ce n'est qu'ensuite que vous supprimez la clé compromise.

L'étape 4 est définitive. Supabase supprime réellement une clé secrète : aucune annulation, aucune réactivation, aucune copie mise de côté que vous pourriez récupérer. C'est pour cela qu'elle vient en dernier.

Supprimer une clé secrète ne déconnecte pas vos utilisateurs. Une clé d'API dit quelle application interroge votre base de données, et le jeton de session d'un visiteur dit quel utilisateur il est. Le second est vérifié avec la clé de signature de votre projet, et c'est une valeur distincte à laquelle vous n'avez pas touché.

Pourquoi une ancienne clé service_role Supabase ne peut pas être remplacée

Parce qu'il n'y a pas de bouton pour cela. La note de dépannage de Supabase indique que la rotation directe des anciens secrets anon, service_role et JWT n'est plus prise en charge, et vous renvoie vers les nouvelles clés.

Invalider une ancienne clé service_role qui a fuité est donc une migration et non une rotation :

1. Créez les nouvelles clés. Cela ajoute sb_publishable_ et sb_secret_ à côté de l'ancienne paire. Les deux systèmes fonctionnent en même temps et rien ne casse.
2. Faites passer votre frontend sur la clé publiable. Dans Lovable ou Bolt, c'est souvent une valeur dans les réglages de votre projet et non une ligne de code.
3. Faites passer tout usage côté serveur sur la clé secrète.
4. Désactivez les anciennes clés dans les réglages de votre projet.

L'étape 4 est un seul interrupteur et il couvre les deux anciennes clés. anon et service_role sont des JWT signés avec le même secret : l'interrupteur qui révoque l'une révoque l'autre, et un frontend qui porte encore l'ancienne clé anon cesse de fonctionner à l'instant où vous le basculez. C'est pour cela que l'étape 2 vient avant.

La désactivation est réversible, et c'est la seule bonne nouvelle de cette section : si quelque chose que vous aviez oublié utilise encore une ancienne clé, vous pouvez les rallumer le temps de corriger. Ce que la migration implique le raconte plus en détail.

D'où la clé a fuité, et comment refermer

Trois causes expliquent presque tout, et les trois se trouvent à l'intérieur de votre propre projet.

Un préfixe VITE_ ou NEXT_PUBLIC_. Ce n'est pas un réglage de sécurité que quelqu'un aurait oublié d'activer. C'est une instruction donnée au build : mets cette valeur dans le bundle. Une variable nommée VITE_SUPABASE_SERVICE_ROLE_KEY a été compilée dans votre JavaScript volontairement, par un outil qui a fait exactement ce qu'on lui demandait.

Une valeur collée directement dans un composant. Aucun préfixe en jeu et aucun fichier .env, juste la clé posée dans une ligne de code parce que c'était le moyen le plus rapide de faire renvoyer quelque chose à une requête.

Du travail qui a sa place sur un serveur. Supprimer un compte, écrire dans une table où vos utilisateurs n'ont pas le droit d'écrire, lire des lignes de tout le monde. On a attrapé la clé parce que le navigateur ne pouvait pas faire le travail, et la solution est de déplacer le travail : une edge function, une route serverless, n'importe quoi que vos visiteurs ne téléchargent pas.

Comment savoir si quelqu'un s'en est servi ?

Le plus souvent, vous ne pouvez pas en être certain. Ce que vous pouvez faire, c'est resserrer la fenêtre et regarder à l'intérieur.

La fenêtre s'ouvre avec le déploiement qui a publié la clé pour la première fois et se referme quand vous l'avez désactivée. Votre projet Supabase conserve des journaux pour l'API et pour la base de données, et c'est sur cette plage qu'il faut les filtrer. Ce que vous cherchez, ce sont des lectures et des écritures que vous ne pouvez pas expliquer : des requêtes vers des tables que votre application ne touche jamais, du trafic à des heures où personne ne s'en servait, des suppressions que personne n'a faites.

Vérifiez ensuite les données elles-mêmes. Nombres de lignes face à ce que vous attendez, vos propres enregistrements de compte, tout ce qui porte un horodatage qui a bougé alors que personne ne travaillait. Un message au support à propos de données qui ont changé toutes seules, c'est ainsi que la plupart de ces cas sont réellement découverts, et il arrive des semaines plus tard.

Une clé service_role n'atteint ni votre prestataire de paiement ni votre envoi d'e-mails. Il reste utile de savoir si c'était la seule clé de votre bundle, car celles qui dépensent de l'argent fuient par le même chemin : ce que 30 998 applications publiaient.

Vérifiez votre application en production avant de conclure

Chargez votre site dans une fenêtre privée, ouvrez le JavaScript que votre navigateur a téléchargé et cherchez-y l'ancienne valeur. Cherchez ensuite la nouvelle, qui ne devrait pas s'y trouver non plus.

Deux choses rendent cette vérification manuelle utile. Un build peut servir un bundle en cache pendant un moment après votre déploiement : le fichier que reçoit un visiteur n'est donc pas toujours celui que vous venez de construire. Et une clé peut se trouver à plus d'un endroit : un deuxième point d'entrée, un service worker, un ancien build encore servi depuis un chemin vers lequel personne ne pointe.

Notre scan gratuit fait cette partie depuis l'extérieur, sur l'URL que vos visiteurs utilisent vraiment, et il décode une clé Supabase assez loin pour en lire le rôle : une clé publiable revient donc avec une coche. Cela prend une vingtaine de secondes et ne demande pas de compte : scannez votre application.

Ce qu'il faut faire maintenant

Une clé service_role lit et écrit chaque ligne de votre base de données. La pire version de cette histoire finit sur une table vide, et le retour de ces lignes dépend de ce que vous sauvegardiez avant que tout cela n'arrive.