La clé d'administration de votre base est-elle dans votre code ?

Deux clés, deux rôles

Un projet Supabase a deux sortes de clés.

• La clé publique, dite « anon » ou « publishable ». Elle est faite pour être dans le navigateur : ce qu'elle permet est limité par les règles d'accès de la base (voir notre guide Supabase : vérifier vos règles d'accès).
• La clé d'administration, dite « service_role » ou « secret » sur les projets récents. Elle contourne toutes les règles d'accès : avec elle, on lit, modifie et efface tout, y compris les comptes administrateurs.

La seconde ne doit exister que sur un serveur. Si elle se trouve dans le code envoyé au navigateur, n'importe quel visiteur peut la lire, et vos règles d'accès ne protègent plus rien.

Ce défaut a une histoire typique : la page d'administration affichait des tableaux vides, parce que les règles d'accès la bloquaient. Quelqu'un, ou un assistant de code, a remplacé la clé publique par la clé d'administration, et « ça a marché ». C'est exactement ce que montre le constat A de notre diagnostic de Studio Kerelune.

Vérification 1 : dans votre navigateur, deux minutes

Ouvrez votre application dans Chrome, Edge ou Firefox, puis les outils de développement (touche F12). Dans l'onglet Sources (ou Débogueur), lancez une recherche dans tous les fichiers (Ctrl + Maj + F, ou Cmd + Option + F sur Mac) et cherchez successivement :

• service_role
• sb_secret_ (préfixe des clés secrètes des projets Supabase récents)
• eyJ (début de toutes les anciennes clés Supabase, publiques comme secrètes)

Pour chaque résultat eyJ…, il faut savoir de quelle clé il s'agit. Copiez la clé entière, puis collez le code ci-dessous dans l'onglet Console. Chrome peut vous demander de taper allow pasting avant d'accepter le collage : c'est une protection normale. Ne collez dans la console que du code dont vous comprenez la source, et ne collez jamais la clé dans un site de décodage en ligne.

const cle = "COLLEZ_LA_CLE_ICI";
JSON.parse(atob(cle.split(".")[1].replace(/-/g, "+").replace(/_/g, "/")));

La console affiche le contenu de la clé. Si vous y lisez "role": "anon", c'est la clé publique, normale. Si vous lisez "role": "service_role", la clé d'administration est livrée à tous vos visiteurs.

Faites-le sur la page d'accueil, puis sur une page de l'espace administrateur si vous en avez une : le code de cette partie est parfois chargé à part.

Vérification 2 : dans votre code

Si vous avez accès au dépôt, cherchez les mêmes mots dans tout le projet. Puis regardez les variables d'environnement : selon l'outil, toute variable dont le nom commence par VITE_, NEXT_PUBLIC_, REACT_APP_ ou PUBLIC_ est copiée dans le code envoyé au navigateur. Une variable VITE_SUPABASE_SERVICE_ROLE_KEY est donc publique par construction, quel que soit l'endroit où on la range.

Profitez-en pour chercher les autres secrets qui n'ont rien à faire côté navigateur :

• sk_live_ et sk_test_ : les clés secrètes de Stripe ;
• rk_live_ : une clé Stripe restreinte, secrète elle aussi ;
• re_ suivi d'une longue suite de caractères, ou une variable RESEND_API_KEY : une clé Resend ;
• AKIA : une clé d'accès Amazon Web Services ;
• "type": "service_account" ou "private_key" : un compte de service Firebase ou Google Cloud, l'équivalent de la clé d'administration.

Vérification 3 : dans l'historique

Une clé retirée du code reste lisible dans l'historique Git, pour toujours, par quiconque a accès au dépôt, et par tout le monde si le dépôt devient public. Dans le dossier du projet :

git log -p --all | grep -o -E "sb_secret_[A-Za-z0-9_-]{10,}|sk_live_[A-Za-z0-9]{10,}|eyJ[A-Za-z0-9_-]{10,}\.eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]+" | sort -u

Chaque ligne affichée est une clé qui a été commitée un jour. Pour celles qui commencent par eyJ, lisez leur contenu avec le code de la vérification 1 : seule une clé dont le rôle est service_role est grave. Un développeur peut aussi lancer un outil dédié, comme gitleaks.

Si vous avez trouvé la clé

L'ordre compte :

1. Changez la clé chez Supabase, avant tout le reste : une clé qui a été publique doit être considérée comme connue. Sur les projets récents, créez une nouvelle clé secrète et supprimez l'ancienne. Sur les anciens projets, le plus propre est de passer aux nouvelles clés (sb_publishable_ et sb_secret_, dans les paramètres du projet, rubrique API Keys), puis de désactiver les anciennes. Faire tourner le secret JWT du projet marche aussi, mais déconnecte tous vos utilisateurs et casse l'application tant que la nouvelle clé publique n'est pas déployée. Dans tous les cas, la page d'administration qui utilisait la clé cessera de marcher jusqu'à l'étape 3 : c'est le prix à payer.
2. Retirez la clé du code envoyé au navigateur, et supprimez la variable d'environnement exposée.
3. Déplacez les opérations d'administration côté serveur : une fonction serveur (Edge Function) qui vérifie que l'appelant est bien administrateur, ou des règles d'accès qui accordent plus de droits aux comptes administrateurs.
4. Si la clé figurait dans l'historique Git d'un dépôt partagé, l'étape 1 suffit à la neutraliser ; réécrire l'historique est facultatif.

Ce que cette vérification ne couvre pas

Trouver zéro clé secrète est une bonne nouvelle, pas une garantie. Restent à vérifier : les règles d'accès de chaque table, les fonctions serveur ouvertes sans vérification de l'appelant, la page d'administration protégée seulement par l'écran (une redirection côté navigateur n'empêche rien), et qui détient les comptes Supabase, Stripe et l'hébergement. C'est ce que couvre notre diagnostic.