Supabase renvoie un tableau vide : la RLS fonctionne-t-elle ?

Des permissions différentes, une même observation

Une requête peut réussir sans renvoyer de ligne. La table est peut-être vide, le filtre ne correspond à rien, ou la RLS masque toutes les lignes correspondantes. Les implications de sécurité diffèrent alors que le client ne reçoit aucune donnée.

Une requête refusée constitue encore un autre cas : des droits manquants peuvent provoquer une erreur de permission. Conserve la preuve observée : lignes reçues, lecture vide, refus ou échec réseau. Un statut HTTP seul ne fournit pas un verdict de sécurité complet.

Cinq cas PostgreSQL reproductibles

Télécharge le script ci-dessous et exécute-le en administrateur dans une base locale jetable. Il crée un rôle visiteur et un schéma de démonstration dans une transaction. Aucun vrai compte ni donnée client n’est nécessaire, et ROLLBACK supprime les objets de l’exemple.

Les deux cas vides sont volontairement différents : filtered contient une ligne avec RLS activée, sans policy de lecture ; empty_table ne contient aucune ligne et laisse la RLS désactivée. Les deux accordent SELECT au visiteur. Le script utilise ce rôle dédié pour éviter le contournement RLS du propriétaire de table.

SET LOCAL ROLE rls_demo_visitor;
SELECT id FROM rls_checker_example.filtered;
-- 0 ligne : la RLS masque une ligne existante.
SELECT id FROM rls_checker_example.empty_table;
-- 0 ligne : table vide, sans RLS.

Diagnostiquer avec une donnée et une identité connues

Sur un projet local ou de staging, crée une ligne fictive dont tu connais le propriétaire. Vérifie son existence avec ton accès administrateur, puis demande-la avec le compte prévu et un autre compte. Utilise le même projet, schéma, table et filtre à chaque étape.

Vérifie la session : une requête envoyée avant la connexion ne représente pas une requête avec un jeton utilisateur valide. Examine les droits et policies du projet. Garde les jetons et le contenu des lignes hors des captures, analytics et rapports publics.

Un bon test comprend un témoin positif : le propriétaire peut lire sa ligne. Il comprend aussi un témoin négatif : l’autre compte ne le peut pas. Si personne ne reçoit de donnée, l’application est peut-être simplement cassée.

Comment RLS Checker présente une réponse vide

Le rapport public classe une lecture anonyme vide comme indéterminée. Il ne la transforme pas en validation de policy. Le checker externe ne dispose ni d’un inventaire privilégié des lignes stockées, ni de la définition de tes policies.

L’exemple local vérifie le comportement des rôles et de la RLS PostgreSQL. Il ne reproduit pas tous les statuts PostgREST, filtres clients ou réglages Supabase. Combine l’observation externe avec les tests de la base et de l’application avant de conclure à la protection des données privées.

Reproduire les cinq cas locaux

À exécuter uniquement dans une base PostgreSQL locale jetable. Le script crée ses données fictives dans une transaction, vérifie les permissions puis annule ses modifications. Il ne se connecte à aucun projet Supabase.

Sources et lectures complémentaires