Où trouver vos clés API Supabase : anon, service_role et URL

Quelque chose vous a demandé votre clé Supabase. Un guide d'installation, un fil de support, ou une IA à qui vous avez demandé de réparer votre app. Vous ouvrez le tableau de bord, vous tombez sur une page contenant une adresse et deux ou trois clés aux noms comme anon et service_role, et chacune a l'air de pouvoir être la bonne réponse.

Ou alors c'est l'autre version de la scène. Quelqu'un a ouvert votre site, a appuyé sur F12, et vous a dit qu'une clé était exposée. Vous voulez maintenant regarder la clé qu'il a trouvée, et vous ne savez pas où elle habite.

La plupart des guides démarrent à la page des clés API. Cela suppose que vous sachiez déjà quel projet Supabase est le vôtre, et c'est précisément l'étape qu'un builder a faite à votre place sans jamais l'expliquer.

Où sont les clés API Supabase ?

Dans le tableau de bord, à l'intérieur de votre projet, sous Settings → API Keys.

Le chemin complet : connectez-vous sur supabase.com, choisissez votre projet dans la liste, ouvrez Settings dans la barre latérale gauche, puis API Keys. Presque tous les guides et toutes les captures d'écran que vous trouverez appellent cette page Settings → API, parce que c'était son nom jusqu'à récemment. C'est la même page et ce sont les mêmes valeurs.

Tout ce qui s'y trouve est l'une de deux choses. Une adresse, qui dit où vit votre projet. Ou une clé, qui décide de ce qu'une requête a le droit de faire une fois arrivée. La page les liste ensemble, dans une seule colonne, dans la même typographie.

Je n'ai jamais configuré Supabase. Quel projet est le mien ?

Lisez l'adresse que votre app utilise déjà. La réponse est dedans.

Chaque projet Supabase possède une référence : une courte chaîne aléatoire qui est aussi la première partie de l'adresse du projet, https://yourreference.supabase.co. Votre app envoie une requête à cette adresse à chaque chargement de page, la chaîne est donc déjà dans votre app, et c'est la même que celle par laquelle le tableau de bord identifie votre projet.

Trois endroits où la trouver sans demander à personne :

• Dans votre builder. Lovable, Bolt, v0 et les autres affichent le projet Supabase connecté quelque part dans les réglages ou le panneau d'intégrations de votre projet.
• Dans votre navigateur. Ouvrez votre app en ligne, appuyez sur F12, passez à l'onglet Network et rechargez la page. Les requêtes qui partent vers quelque chose en .supabase.co portent la référence dans leur adresse.
• Dans le code source de la page, si votre app écrit l'adresse dans le HTML plutôt que dans un fichier de script.

Connectez-vous ensuite sur supabase.com et comparez cette référence à votre liste de projets. Les builders connectent Supabase via votre propre compte, le projet dort donc en général dans un tableau de bord que vous avez créé une fois sans jamais y revenir. Une fois entré dans un projet, la référence apparaît dans la barre d'adresse du navigateur, ce qui vous permet de confirmer que vous êtes dans le bon avant d'en copier quoi que ce soit.

Les quatre choses sur cette page

Une adresse et trois clés. Deux ont leur place dans votre app, deux ne quittent jamais le tableau de bord.

Il y a un raccourci posé sur la page elle-même. Supabase affiche l'URL du projet et la clé publiable là où vous pouvez les lire, et couvre la clé secrète et la valeur JWT de points jusqu'à ce que vous demandiez à les voir. Les deux qu'il couvre sont exactement les deux qui n'ont jamais leur place dans votre app.

Où se trouve l'URL de mon projet Supabase ?

À deux endroits, et vous en avez probablement un sous les yeux. Le tableau de bord l'imprime en haut de Settings → API Keys, sous le libellé Project URL. La barre d'adresse de votre navigateur montre la même chaîne dès que votre appli parle à Supabase, sous la forme https://yourreference.supabase.co.

Dans le code elle porte l'un de trois noms, et les trois contiennent cette même chaîne :

• VITE_SUPABASE_URL dans une appli construite avec Vite, ce qui couvre l'essentiel de ce que produisent Lovable et Bolt
• NEXT_PUBLIC_SUPABASE_URL dans une appli Next.js
• SUPABASE_URL sur un serveur, dans une edge function ou dans un script

Le milieu, yourreference, est la référence de votre projet. C'est la chaîne par laquelle le tableau de bord identifie votre projet, et celle à comparer quand vous avez plusieurs projets et aucune idée duquel appartient à cette appli.

C'est une adresse plutôt qu'un secret, et c'est pour cela qu'elle est affichée en clair à côté de la clé publiable.

Où est la clé service_role, et qu'est-ce que SUPABASE_SERVICE_ROLE_KEY ?

Sur la même page que tout le reste. Ouvrez Settings → API Keys et cherchez la ligne service_role, ou secret sur un projet créé récemment. Contrairement à l'URL et à la clé publiable, sa valeur reste derrière un bouton d'affichage tant que vous ne la demandez pas.

Ce bouton est le seul indice que le tableau de bord vous donne que celle-ci est différente, et il mérite d'être pris au sérieux : Supabase masque exactement les valeurs qui ne doivent jamais atteindre un navigateur.

SUPABASE_SERVICE_ROLE_KEY est un nom de variable plutôt qu'une deuxième clé : derrière lui se trouve la valeur que vous venez d'afficher. Vous la croiserez dans un fichier .env, dans les réglages d'environnement de votre hébergeur, ou dans les secrets d'une edge function. Ce qui compte, c'est le préfixe devant. Une variable nommée VITE_SUPABASE_SERVICE_ROLE_KEY ou NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY est compilée dans le JavaScript que vos visiteurs téléchargent, donc la clé est publique dès le déploiement. Ces préfixes sont des instructions de publication, pas des oublis.

Sa place, c'est une edge function, un gestionnaire de webhook, une tâche planifiée ou un script de migration : partout où le code tourne sur une machine que vous contrôlez et où aucun visiteur ne peut ouvrir le fichier. C'est la clé qui ignore complètement Row Level Security, elle lit donc chaque ligne de chaque table quoi que disent vos règles.

Si vous n'êtes pas certain que la vôtre est restée sur le serveur, notre analyseur de sécurité de site gratuit lit votre site en ligne depuis l'extérieur et nomme les clés qu'il trouve, en une vingtaine de secondes.

De quelle clé mon app a-t-elle besoin ?

L'URL du projet et la clé publiable. Rien d'autre, jamais.

Votre app tourne dans le navigateur de vos visiteurs et parle à Supabase depuis là, ces deux valeurs partent donc vers chaque visiteur par construction. Ce n'est pas une fuite et cela ne l'a jamais été. Ce qui empêche un inconnu de lire toute votre base avec une clé publiable, c'est Row Level Security : les règles qui décident, ligne par ligne, qui a le droit de voir quoi.

Ce sont donc ces règles qu'il faut vérifier quand vous vous inquiétez, et les activer n'est pas la même chose qu'être protégé. La version longue de pourquoi une clé est sûre en public se trouve dans quelles clés API sont sûres dans votre frontend.

Comment savoir quelle clé mon app a réellement embarquée ?

Le tableau de bord ne vous le dira pas. Il liste les clés que votre projet possède, pas celle qui est partie dans votre app.

Ce sont deux questions différentes, et seule la seconde peut vous coûter cher. Un projet peut avoir une page de réglages parfaitement ordinaire et avoir quand même sa clé secrète collée dans un fichier que n'importe qui peut ouvrir. Pour y répondre, il faut lire la clé qui est réellement dans l'app.

Sur un projet récent, lisez les premiers caractères. sb_publishable_ est celle qui a sa place là. sb_secret_ est celle dont il faut s'occuper aujourd'hui.

Sur un projet ancien, il faut regarder à l'intérieur de la clé. anon et service_role sont des JWT : trois blocs séparés par des points, dont celui du milieu se décode en texte parfaitement lisible. Il porte un champ role, et ce seul mot fait toute la différence entre les deux. Comment le lire.

Si vous préférez ne pas parcourir votre app à la main, notre scan gratuit lit votre site en ligne depuis l'extérieur et nomme les clés qu'il voit, ainsi que la réponse de vos tables à un inconnu qui demande. Cela prend une vingtaine de secondes et ne demande aucun compte : scanner votre app.

Et si la clé secrète est déjà dans mon app ?

Occupez-vous de la clé elle-même avant de toucher au moindre code, et sur Supabase cela ne veut peut-être pas dire ce que vous croyez.

Le conseil habituel est de faire tourner la clé : en générer une nouvelle, révoquer l'ancienne, et la valeur qui a fuité cesse de fonctionner. Cela reste vrai pour les nouvelles clés. Un projet peut détenir plusieurs clés sb_secret_ en même temps et les révoquer une par une, remplacer l'une d'elles ne signifie donc plus une minute pendant laquelle tout ce qui s'en servait est cassé.

Pour la paire d'origine, cela ne tient plus du tout. Les notes de dépannage de Supabase indiquent qu' il n'est plus possible de faire tourner les anciens secrets anon, service_role et JWT. Neutraliser une ancienne clé service_role qui a fuité passe par la création des nouvelles clés, le basculement de votre app et de votre code serveur, puis la désactivation de l'ancienne paire. Ce que cette migration implique tient en quelques étapes dans le tableau de bord et une valeur échangée dans votre app, ce qui est nettement plus facile un après-midi tranquille que le jour où vous en avez besoin.

Ce qu'il faut faire maintenant

Si vous préférez traiter cela comme une liste, la checklist de sécurité en 10 minutes couvre ce point et les autres choses à désactiver dans une app fraîchement lancée, et nous avons un guide en langage clair pour les apps Supabase.