Identifier le type de clé avant de conclure
Le frontend utilise une configuration publique pour communiquer avec Supabase. Un visiteur peut la retrouver. Renommer une variable, minifier un bundle ou supprimer une source map ne crée pas une barrière de contrôle d’accès.
La clé publique identifie le composant applicatif. La session identifie séparément l’utilisateur connecté. Posséder une clé publique ne devrait donc pas suffire à obtenir les données privées des utilisateurs.
Vérifier les données accessibles avec cette clé
Deux applications peuvent publier le même type de clé anon. L’une autorise la lecture des articles publiés ; l’autre rend des commandes privées accessibles. La présence de la clé ne distingue pas ces situations. Les permissions et le public prévu pour ces données le font.
L’exposition du schéma dans la Data API, le droit SELECT et les policies RLS applicables déterminent ensemble les lignes lisibles. Une RLS désactivée ne prouve pas un accès anonyme si les droits nécessaires sont absents. Une RLS activée ne garantit pas non plus la confidentialité si une policy autorise une lecture très large.
RLS Checker part de l’URL de l’application et teste la surface anonyme observable. Tu n’as pas à coller de clé dans son formulaire. Si une table privée est signalée lisible, vérifie son public prévu et corrige les permissions. Si la découverte est partielle, examine les ressources non testées dans le projet.
Si la clé exposée est publique
Confirme d’abord le type publishable ou anon. Vérifie ensuite les lectures anonymes de données privées et l’isolation de deux comptes connectés. Une session administrateur ne représente pas les permissions d’un visiteur.
Changer seulement la clé publique ne corrige pas des permissions trop larges : la nouvelle clé utilisée par le navigateur sera elle aussi publique. Corrige les droits et policies, déploie et reteste. Certaines tables peuvent nécessiter une lecture publique légitime ; évite une modification globale qui casserait cet usage.
Si la clé exposée est privilégiée
Retire la clé secret ou service_role du code client et suis la procédure de révocation ou de renouvellement du fournisseur. Remplace l’opération du frontend par une opération serveur qui contrôle les droits de son appelant. Vérifie les fichiers construits et la configuration de déploiement, pas seulement les sources.
Examine les journaux d’accès et les données qui étaient accessibles pendant l’exposition. Supprimer un fichier ne révoque pas un credential déjà copié. Ce checker de lectures anonymes ne recherche pas exhaustivement les secrets et ne peut pas établir si un credential exposé a été utilisé.