Définir qui doit accéder à chaque donnée
Choisis une ressource concrète : un profil, une commande ou un article publié. Décide si elle doit être publique, privée à son propriétaire ou partagée dans une organisation. Un catalogue lisible publiquement n’est pas automatiquement vulnérable. Une commande privée lisible par un visiteur pose une autre question.
Prépare des données fictives dont tu connais les propriétaires. Utilise au moins deux comptes distincts et un visiteur non connecté. Garde les credentials administrateur hors des requêtes de test : leurs privilèges peuvent masquer les restrictions que tu cherches à vérifier.
Tester l’application publique déployée
Saisis l’URL HTTPS publique dans RLS Checker, uniquement pour une application que tu possèdes ou es autorisé à auditer. Le service recherche la configuration Supabase et les références de tables observables dans les ressources publiques, puis effectue des lectures anonymes bornées.
Lis le résultat et la couverture ensemble. Une lecture refusée signifie que cette requête a été bloquée. Une réponse vide reste indéterminée. Une configuration ou une table non découverte ne permet pas de conclure que les données sont protégées.
Ce regard extérieur peut révéler une différence entre ta configuration locale et ton déploiement. Il n’inspecte pas le SQL de tes policies et ne teste ni les comptes connectés, ni les écritures, ni Storage, ni toutes les routes API. Poursuis donc avec les tests du projet.
Vérifier les frontières entre comptes et les opérations
Sur un projet local ou de staging, connecte le compte A et demande une ligne connue appartenant à B par l’API utilisée par ton application. Inverse ensuite les comptes. Vérifie aussi un accès légitime : une application qui ne renvoie plus rien à personne n’est pas nécessairement bien sécurisée.
Teste SELECT, INSERT, UPDATE et DELETE séparément lorsque ton application les utilise. Une policy de lecture ne prouve rien sur les écritures. Définis le propriétaire attendu avant chaque opération et réserve ces vérifications à des données fictives jetables.
Supabase combine les droits sur les schémas et tables avec les policies RLS. Examine les deux. Les tests automatisés doivent utiliser les rôles concernés, et non le propriétaire de table, un superutilisateur ou un rôle qui contourne la RLS. Les outils de test Supabase permettent de conserver ces vérifications après chaque migration.
Reproduire l’ambiguïté d’une réponse vide
Le script SQL téléchargeable crée cinq cas fictifs dans une base locale jetable. Il utilise un rôle visiteur sans BYPASSRLS, compte les lignes visibles, vérifie un refus de permission et annule tous les objets créés par ROLLBACK.
Les tables filtered et empty_table renvoient toutes deux zéro ligne. La première contient une ligne masquée par la RLS ; la seconde ne contient rien et n’a pas de RLS. Une lecture externe vide ne permet donc pas de certifier les policies. Ce script teste PostgreSQL, pas la passerelle HTTP Supabase ni le scanner VICE complet.
Retester après le déploiement des corrections
Après une correction de droits ou de policy, relance les tests entre comptes et le contrôle externe. Vérifie que les accès légitimes fonctionnent encore et que la donnée privée précédemment exposée ne peut plus être lue par le mauvais rôle. Conserve un cas fictif de non-régression.
Pour une couverture authentifiée de l’application, la documentation VICE décrit le parcours d’audit plus large. Le résultat du checker gratuit reste limité aux lectures anonymes Supabase et ne constitue pas une certification de sécurité.
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.
Télécharger le script SQL