Pour vérifier que vos données Supabase sont protégées, allez dans Authentication > Policies de votre tableau de bord. Si une table affiche l'étiquette rouge "RLS disabled", vos données sont exposées publiquement. Vous pouvez aussi tester l'exposition en exécutant await supabase.from('votre_table').select('*') dans la console de votre navigateur.
Supabase est la base de données backend favorite des générateurs d'applications IA (Lovable, Cursor, Bolt.new). Son architecture "Data API" permet d'interroger directement la base PostgreSQL depuis le frontend React en utilisant une clé publique anonyme (anon key).
C'est magique, mais cela repose sur un pilier de sécurité souvent oublié par l'IA : le Row Level Security (RLS).
Qu'est-ce que le RLS (Row Level Security) ?
Le RLS est un système natif à PostgreSQL qui permet de définir des règles d'accès précises au niveau de chaque ligne de votre base de données. Il permet de dicter que :
- "Seul l'utilisateur connecté peut lire ses propres documents."
- "Seuls les administrateurs peuvent ajouter de nouveaux produits."
- "Tout le monde peut lire la liste des articles publics, mais personne ne peut les modifier."
Le piège critique du Vibe Coding
Lorsque l'IA génère les requêtes SQL pour créer vos tables, elle omet très souvent d'activer ce fameux RLS par souci de simplicité pour le développement local.
Risque de fuite de données massive
Si une table Supabase n'a pas de RLS activé, l'API autorise par défaut toutes les opérations (SELECT, INSERT, UPDATE, DELETE) pour n'importe qui possédant votre clé anonyme publique (qui est visible dans le code source de votre site web).
Autrement dit : N'importe quel internaute un peu technique peut ouvrir la console de son navigateur, copier votre clé publique NEXT_PUBLIC_SUPABASE_ANON_KEY, et vider votre base de données ou télécharger la liste complète de vos clients et leurs adresses e-mails.
Comment auditer vos règles Supabase ?
Il existe deux manières de vérifier si vous êtes vulnérable.
Méthode 1 : L'interface visuelle Supabase
- Connectez-vous à votre tableau de bord Supabase.
- Allez dans le menu de gauche : Authentication > Policies.
- Vous verrez la liste de toutes vos tables. Si vous voyez une étiquette rouge "RLS disabled" (RLS désactivé) à côté d'une table contenant des données d'utilisateurs, votre application est grande ouverte.
Méthode 2 : L'approche agressive (Pen-Test frontend)
Vous pouvez tester vous-même la vulnérabilité depuis la console de développement de votre navigateur (Touche F12) sur votre propre site en production :
// A coller dans la console du navigateur si supabase est globalement accessible
const { data, error } = await supabase.from('users').select('*');
console.table(data);
Si cette commande vous renvoie les données privées des autres utilisateurs de l'application, vous avez une faille de type IDOR / Data Exposure très grave.
Comment corriger et sécuriser votre BDD ?
La correction se fait en deux étapes obligatoires :
- Dans la console Supabase, cliquez sur le bouton "Enable RLS" pour chaque table.
- Créez ensuite des "Policies". Par exemple, la politique SQL pour permettre à un utilisateur de ne lire que ses propres lignes :
CREATE POLICY "Les utilisateurs lisent leurs données"
ON public.users
FOR SELECT
USING ( auth.uid() = id );
Une fois le RLS activé et les policies correctement configurées, l'API publique de Supabase devient un coffre-fort sécurisé. C'est l'une des étapes de notre checklist avant mise en production d'une application IA.
L'Analyse Express GVO et Supabase
L'Analyse Express repère si votre clé publique (anon key) est visible sur votre site (ce qui est normal, mais requiert le RLS). En revanche, seul l'Audit Complet (qui se connecte à votre code source et votre base de données) peut certifier mathématiquement que vos règles SQL (Policies) ne comportent aucune faille de logique.