Supabase te donne une base de données et une API en quelques minutes, et c'est précisément là le danger : l'API est exposée dès le premier instant. Si tu ne configures pas la sécurité, n'importe qui avec ta clé publique peut lire et écrire dans tes tables. Voici ce qu'il faut vérifier.
RLS activé sur TOUTES les tables
Row Level Security est la barrière principale de Supabase. Sans elle, la clé anon peut interroger des tables entières directement depuis le navigateur. L'erreur classique du vibe coder est de créer une nouvelle table à la va-vite et d'oublier d'activer le RLS.
Vérifie table par table dans le tableau de bord : si l'une apparaît sans RLS, elle est ouverte au public. L'activer ne suffit pas non plus : une table avec RLS activé mais sans policies refuse tout, et une avec une policy trop permissive ne protège rien.
service_role face à anon
La clé anon est publique et va dans le frontend : elle est faite pour être gouvernée par le RLS. La clé service_role contourne complètement le RLS et a un accès total. Elle ne doit jamais apparaître dans le navigateur ni dans une variable NEXT_PUBLIC_.
Utilise-la uniquement sur le serveur, dans des edge functions ou des backends de confiance. Si tu soupçonnes une fuite, fais-la tourner immédiatement depuis le tableau de bord.
Des policies qui reflètent vraiment qui peut quoi
Une policy à true pour tout le monde laisse la table ouverte même avec le RLS activé. Écris des policies précises : qu'un utilisateur ne lise et ne modifie que ses propres lignes, généralement en comparant auth.uid() avec la colonne propriétaire. Sépare les règles par opération (select, insert, update, delete) : parfois tu veux autoriser la lecture mais pas la suppression.
Storage : les buckets ont aussi des règles
Le stockage de fichiers utilise ses propres policies. Un bucket public sert n'importe quel fichier par URL à quiconque l'a. Décide sciemment quels buckets sont publics et protège le reste avec des policies basées sur l'utilisateur. Mets les documents privés dans des buckets privés, pas dans un bucket public avec des noms difficiles à deviner.
Secrets et clés hors du frontend
Au-delà de la service_role, vérifie qu'aucune clé tierce (Stripe, email, IA) n'est intégrée dans le JavaScript client. L'IA les glisse parfois là pour faire marcher quelque chose vite, et elles restent visibles pour toujours.
Scanaris relit ton Supabase pour toi
Scanaris inclut un audit Supabase optionnel qui vérifie si tes tables ont le RLS et détecte les clés exposées dans le frontend. C'est un contrôle en lecture seule sur ce qui est déjà public, et chaque trouvaille vient avec un prompt prêt à coller dans ton IA. Lance-le avant le lancement et tu sauras si tu as laissé une porte ouverte.