10 min de lecture - Jetons Supabase à portée limitée : remplacez les accès CI globaux

Supabase a rendu ses jetons d’accès personnels à portée limitée accessibles à tous le 6 octobre 2026. La veille, GitHub avait ajouté des motifs de détection pour les jetons OAuth Supabase et ces nouveaux jetons. Les équipes peuvent repérer les accès trop larges, les remplacer et réduire le coût d’une fuite.

Ce chantier dépasse l’échange d’une variable d’environnement. Un jeton partagé par la CLI, un déploiement et un agent IA peut cacher des niveaux d’autorité très différents. Cartographiez ses consommateurs avant la bascule pour éviter une panne ou le retour du même risque sous un autre préfixe.

Visez une identité par tâche, avec un responsable, un périmètre et les permissions minimales que la tâche peut justifier.

La nouveauté concerne le plan de contrôle

Les jetons d’accès personnels Supabase authentifient les appels à l’API de gestion et aux outils qui s’appuient sur elle, dont la CLI Supabase et le serveur MCP. Selon l’annonce de disponibilité générale de Supabase, un jeton peut viser certains projets ou organisations, recevoir des droits de lecture ou d’écriture et expirer dans un délai maximal d’un an. Les anciens jetons restent actifs jusqu’à leur expiration ou leur suppression.

Rien ne réduit automatiquement les droits d’un ancien jeton. La documentation Supabase sur les jetons d’accès personnels précise qu’un jeton classique reprend les permissions du compte sur les organisations et projets présents ou futurs. Un jeton limité réduit les droits existants ; il n’en crée pas de nouveaux.

Le journal GitHub du 5 octobre nomme deux nouveaux types détectés : supabase_oauth_access_token et supabase_scoped_personal_access_token. La découverte progresse, mais elle n’identifie ni le propriétaire du jeton ni la pertinence de ses droits. La détection donne l’alarme ; le modèle d’accès fixe les dégâts.

Ne confondez pas jetons de gestion et clés de projet

Appeler chaque identifiant Supabase « clé API » devient dangereux pendant un incident : chacun demande une mesure de confinement distincte.

Le guide Supabase des clés API documente cette séparation. Les clés publiques sont prévues pour les clients publics et reposent sur des droits et des politiques RLS corrects. Les clés secrètes restent dans des composants serveur contrôlés et contournent les politiques RLS. Aucune des deux n’est un jeton d’accès personnel destiné à l’API de gestion.

Classez d’abord l’identifiant. Renouveler une clé publique sans corriger une politique RLS trop large traite le mauvais problème. Effacer un jeton de Git sans le révoquer le laisse utilisable.

Cartographiez les consommateurs avant tout remplacement

Partez des usages actuels. Cherchez les noms de secrets CI, les déploiements, les tâches planifiées, les stockages locaux et les configurations MCP. N’affichez jamais la valeur d’un secret. Consignez plutôt :

Ne créez pas un jeton unique pour « la CI ». Une prévisualisation, un job qui déploie une Edge Function et un agent de diagnostic n’ont pas besoin des mêmes droits. Des jetons séparés permettent d’en révoquer un sans arrêter les autres.

Prouvez le jeu minimal de permissions

Commencez par un projet et la lecture seule. Ajoutez une capacité uniquement après un échec explicite. Supabase documente les permissions de l’API de gestion, de la CLI et des outils MCP. Par exemple, supabase link demande un accès en lecture aux paramètres du projet, aux clés API et à leurs secrets. Une commande de base de données peut ensuite utiliser un mot de passe distinct, hors du périmètre du jeton.

Inventoriez donc tous les identifiants du job, y compris les mots de passe, au-delà de SUPABASE_ACCESS_TOKEN.

Pour un usage MCP sans surveillance, la documentation Supabase demande un projet, le mode lecture seule, des groupes de fonctions restreints et un jeton limité aux outils conservés. Supabase recommande l’OAuth interactif pour l’usage courant ; le jeton manuel vise surtout la CI ou un client sans navigateur.

Gardez l’approbation des écritures hors de la décision du modèle. Le périmètre du jeton limite ce qu’un agent peut tenter, tandis qu’un chemin de changement relu décide de ce qui doit être exécuté. Notre guide des contrôles de cybersécurité pour le développement assisté par IA traite la frontière plus large entre code, données et livraison.

Migrez sans masquer les hypothèses erronées

Remplacez un consommateur à la fois :

1. Nommez le responsable, le projet, les commandes et les écritures prévues.
2. Créez un jeton distinct, à expiration courte, avec les droits testés.
3. Installez-le sans l’exposer dans les journaux, arguments ou fichiers produits.
4. Testez le workflow, ses échecs et son retour arrière hors production.
5. Basculez, vérifiez une exécution, supprimez l’ancien jeton et consignez la révocation.

Surveillez les connexions implicites. Supabase indique que le flux navigateur de supabase login crée encore un jeton au niveau du compte. Dans la CI, transmettez la valeur limitée avec SUPABASE_ACCESS_TOKEN ou utilisez supabase login --token ; ne supposez pas qu’une connexion réussie a produit un identifiant étroit.

Gardez l’ancien jeton uniquement pendant le test. Si le workflow exige un périmètre déraisonnable, documentez la permission manquante ou la limite du produit au lieu de restaurer discrètement l’accès global.

Transformez une alerte en dossier d’incident

GitHub indique que la détection de secrets examine l’historique Git de toutes les branches ainsi que plusieurs espaces de collaboration, dont les pull requests, issues, discussions, wikis et gists secrets. La disponibilité varie selon le type de dépôt et l’offre GitHub, comme l’explique la présentation de Secret Scanning. Vérifiez votre couverture au lieu de supposer que chaque dépôt privé en bénéficie.

Lorsqu’une alerte arrive, nommez un responsable et considérez l’identifiant comme compromis. Le guide GitHub de résolution des alertes demande de mettre à jour les services dépendants, de remplacer l’identifiant et d’examiner les journaux du fournisseur à la recherche d’une activité non autorisée. Supprimer la chaîne de la branche courante ne la révoque pas, et GitHub ne ferme pas automatiquement l’alerte après la modification du fichier.

Consignez le lieu de l’exposition, l’autorité du jeton, tout usage inattendu et l’heure du remplacement. Révoquez d’abord si l’exposition est publique ou si un abus paraît plausible. Ne réécrivez pas l’historique Git partagé par défaut : la révocation neutralise le jeton sans perturber les clones et références.

La fiche OWASP sur la gestion des secrets ajoute ce qu’un scanner ne fournit pas : responsable, cycle de vie, identités CI distinctes, droits réduits, surveillance, rotation et révocation. Le détecteur devient alors une réponse répétable.

La décision pour une petite équipe

Migrez maintenant si un jeton classique persistant se trouve dans la CI, un script d’automatisation ou un client MCP authentifié manuellement. Commencez par le consommateur en lecture seule le plus simple, apprenez le modèle de permissions, puis traitez les jobs de déploiement avec davantage de tests et d’approbation. Supprimez les jetons inutilisés au lieu de les reproduire avec un périmètre plus étroit.

Suspendez une bascule si personne ne possède le workflow ou si ses autres identifiants restent inconnus. Menez une courte découverte au lieu d’accorder une exception globale. L’approche de services d’Exceev relie évaluation, ingénierie et transfert pour accompagner ce travail.

Avant de supprimer le dernier jeton large, vérifiez les points suivants :

• chaque consommateur actif dispose de sa propre identité et d’un responsable ;
• chaque jeton atteint uniquement le projet ou l’organisation requis ;
• les droits d’écriture correspondent à des commandes ou outils observés ;
• l’expiration et le renouvellement ont un responsable et un chemin testé ;
• la détection couvre les dépôts et espaces de collaboration utilisés ;
• le runbook d’incident révoque les identifiants, examine l’activité et met à jour chaque consommateur.

Un jeton limité réduit le coût d’une erreur uniquement lorsque l’ancienne autorité disparaît. La migration se termine lorsqu’un jeton de workflow exposé ne peut toucher qu’un job connu dans une frontière connue, pas lorsque le tableau de bord affiche un nouveau type de jeton.

Sources et limites

Nous avons ouvert et relu chaque source ci-dessous le 7 octobre 2026.

• L’annonce Supabase sur les jetons à portée limitée établit la date, les périmètres, l’expiration et le maintien des jetons existants.
• Le guide Supabase des jetons d’accès personnels documente les droits, la CLI, les permissions et les identifiants de base de données.
• Le guide Supabase des clés API distingue clés publiques, clés secrètes, sécurité au niveau des lignes et identifiants de gestion.
• Le guide MCP de Supabase documente l’authentification, la CI, la restriction à un projet, la lecture seule et les groupes de fonctions.
• L’annonce GitHub sur les détecteurs nomme les nouveaux types de jetons OAuth Supabase et de jetons personnels à portée limitée détectés.
• La présentation GitHub de Secret Scanning documente les surfaces, les réanalyses, la disponibilité et la réponse.
• Le guide GitHub de résolution des alertes documente la réponse à un secret compromis et la fermeture manuelle de l’alerte.
• La fiche OWASP sur la gestion des secrets fournit des recommandations indépendantes sur l’inventaire, la CI, la rotation et la révocation.

Nous n’avons pas inspecté de compte Supabase, testé les contrôles disponibles, exécuté Secret Scanning sur un dépôt ni mesuré de migration. Le comportement du produit, les noms de permissions, les offres GitHub et la couverture de détection peuvent changer après la date de revue. Le modèle d’exploitation proposé ne constitue ni un avis juridique, ni un constat de conformité, ni une garantie de sécurité pour Exceev ou pour un client.