Supabase et ta base : comprendre qui peut lire quoi (et régler les accès)

Sur Supabase, la clé « publishable » qui circule dans ton app est publique par conception : ce n'est pas une faille, c'est le mode d'emploi. La protection de tes données repose entièrement sur les règles d'accès, le Row Level Security (RLS) : des règles écrites table par table qui disent qui peut lire, écrire ou supprimer quoi. Une app Supabase bien réglée est parfaitement sûre ; une app sans règles est un système dont les autorisations restent à définir.

Si ton app utilise Supabase directement ou via Lovable, ce sujet te concerne. Les projets Lovable peuvent désormais utiliser Supabase ou Lovable Cloud, tous deux fondés sur des contrôles d'accès compatibles avec RLS. Voici comment les comprendre et les examiner avec les précautions nécessaires.

Comment ça marche, en deux paragraphes

Ta base contient des tables : clients, commandes, messages. Quand ton app interroge la base, Supabase vérifie d'abord les règles de la table concernée. Une règle dit par exemple : « un utilisateur connecté peut lire les lignes dont la colonne user_id est la sienne ». Pas de règle qui autorise ? Accès refusé. C'est un système simple et robuste : le videur est à la porte de chaque table.

Le point qui surprend : par défaut, activer le RLS sur une table sans écrire de règle bloque tout, et oublier de l'activer laisse tout passer pour qui connaît la clé publique (c'est-à-dire tout le monde, puisqu'elle est dans le navigateur). Toute la sécurité tient donc à deux questions : le RLS est-il activé partout, et les règles disent-elles vraiment ce que tu crois ?

Le test des cinq minutes

Ouvre ton tableau de bord Supabase, section « Table Editor » ou « Database » :

1. Liste tes tables. Pour chacune, vérifie que la mention RLS est active. Supabase affiche d'ailleurs un avertissement visible sur les tables exposées sans règles : ne l'ignore pas.
2. Lis les règles existantes (section « Policies »). Même sans être développeur, tu peux repérer les noms suspects : une règle « Enable read access for all users » sur ta table clients dit exactement ce qu'elle dit.
3. Compte les tables sans aucune règle. RLS actif + zéro règle = table inaccessible (ton app plantera dessus) ; RLS inactif = table ouverte.

Ce test ne remplace pas un audit, mais il répond à la question la plus urgente : « est-ce que quelqu'un peut lire mes données là, maintenant ? »

Les trois pièges classiques des apps vibe-codées

1. La règle trop généreuse

L'IA veut que l'app fonctionne du premier coup ; la règle la plus simple qui marche, c'est « tout le monde peut tout lire ». Résultat fréquent : les profils, emails et messages de tous les utilisateurs lisibles par chacun d'eux. La correction consiste à réécrire la règle autour de l'identité (auth.uid()), table par table.

2. La clé de service côté navigateur

Supabase fournit aussi une clé « service » qui contourne toutes les règles : elle est faite pour le serveur, jamais pour le navigateur. Quand l'IA la colle côté front pour « faire marcher » une fonctionnalité, toutes les règles du monde ne protègent plus rien. Le test : cherche « service_role » dans ton code exporté (tu l'as bien branché sur GitHub ?).

3. La table oubliée

Le RLS se règle table par table, et les tables ajoutées en cours de route (la fonctionnalité de la semaine 3, la table de logs) sont les plus souvent oubliées. D'où la règle d'or : à chaque nouvelle table, la question des règles se pose immédiatement, pas « plus tard ».

Corriger sans casser

Écrire des règles RLS correctes demande de comprendre ton modèle de données : qui possède quoi, qui partage quoi avec qui. C'est un travail de développeur, mais un travail borné : quelques heures pour une app raisonnable, pas des semaines. Dans un Scan, c'est systématiquement le premier point vérifié ; dans une Intervention, les règles sont réécrites et testées avec des comptes de démonstration, sans interrompre ton app. Et avant d'ouvrir aux vrais utilisateurs, la checklist complète mérite un passage entier.