Sécurité Supabase RLS : audit manuel ou scan automatisé ?

Row Level Security (RLS) permet de limiter l’accès aux lignes d’une base Supabase. Une bonne configuration applique les règles attendues aux rôles concernés. Les rôles privilégiés, notamment service_role, peuvent toutefois contourner ces restrictions. Des règles trop permissives peuvent exposer des données alors que les tables semblent protégées.

Deux approches permettent de vérifier RLS : examiner les règles manuellement et effectuer des tests automatisés. Elles sont complémentaires. Comprendre leurs limites aide à vérifier que les autorisations correspondent réellement à vos besoins.

RLS est une fonction de PostgreSQL que Supabase permet d’activer par table. Elle refuse l’accès aux lignes pour les rôles concernés tant qu’aucune règle ne l’autorise. Les propriétaires et les rôles dotés de privilèges de contournement constituent des exceptions. Les règles utilisent notamment l’identité et les attributs de l’utilisateur. La fonction auth.uid() est fréquemment utilisée : une expression comme using (auth.uid() = user_id) limite l’accès aux lignes associées à l’utilisateur connecté, selon les opérations couvertes par la règle.

Le principe est simple, mais les erreurs sont parfois discrètes : une application peut continuer de fonctionner malgré des autorisations incorrectes.

Voici quelques erreurs de configuration fréquentes :

• RLS activé sur certaines tables seulement. Une nouvelle table créée par migration peut être exposée sans RLS. Les rôles disposant des droits appropriés sur la table peuvent alors accéder à ses lignes.

• Une règle plus permissive que prévu. using (true) autorise toutes les lignes pour les rôles et opérations concernés. Une règle temporaire de développement peut ainsi rester active en production.

• L’utilisation systématique de service_role. Les requêtes exécutées avec ce rôle contournent RLS. Le code serveur doit donc appliquer les contrôles d’autorisation nécessaires.

• Une comparaison avec la mauvaise colonne. auth.uid() = id ne vérifie pas la propriété de la ligne si id désigne sa clé primaire plutôt que son propriétaire. La présence d’une règle ne suffit pas à garantir son adéquation.

• Des modifications et suppressions trop largement autorisées. Une lecture correctement limitée ne garantit pas que les règles d’écriture ou de suppression le soient aussi.

Ces problèmes ne produisent pas toujours d’alerte visible dans l’application, ce qui explique pourquoi ils peuvent rester présents en production.

Un audit manuel consiste à examiner directement les règles d’accès, table par table.

Commencez par inventorier les tables et vérifier l’activation de RLS. Pour chaque table, rapprochez les règles des accès attendus : qui peut lire, créer, modifier ou supprimer une ligne ? Vérifiez les colonnes utilisées dans les expressions et les rôles auxquels chaque règle s’applique.

Examinez aussi le code de l’application : quelle clé est utilisée pour les requêtes des utilisateurs ? Certaines passent-elles par service_role ? Testez ensuite plusieurs identités. Un utilisateur ne doit consulter ou modifier que les lignes auxquelles il est autorisé à accéder.

Cette revue est utile, mais comporte plusieurs limites.

• La couverture dépend des cas testés. Sans tester la suppression avec une seconde identité, une règle trop large peut passer inaperçue. À l’inverse, avec RLS actif, l’absence de règle de suppression applicable interdit cette opération.

• Les conclusions vieillissent. Une revue réalisée il y a trois mois ne couvre pas automatiquement une table ajoutée la semaine dernière.

• Les mêmes hypothèses peuvent être répétées. La personne qui a écrit les règles peut avoir du mal à remettre en question ses propres choix.

• Les preuves doivent être conservées. Une revue sans périmètre documenté ni résultats de tests est difficile à reproduire et à comparer dans le temps.

La lecture des règles permet de vérifier leur cohérence avec votre modèle d’accès. Pour savoir ce que la base autorise effectivement, il faut aussi exécuter des tests et en conserver les résultats.

Un contrôle automatisé teste les accès disponibles depuis le contexte configuré. Il permet d’observer ce que la couche de données autorise réellement, plutôt que de se limiter à la lecture des règles.

Cette approche présente trois intérêts. Elle répète les contrôles sur les tables et routes accessibles dans le périmètre configuré ; un scan externe ne peut pas inspecter toutes les règles sans accès adapté. Elle produit aussi des preuves : ressource concernée, conditions du test et résultat observé. Enfin, elle est reproductible : relancer les mêmes contrôles permet de suivre les changements.

VICE analyse les applications web et les configurations Supabase/RLS, puis présente les constats avec des preuves et des conseils de correction. Une déclaration manuelle demande une revérification ; seul un rescan comparable peut confirmer la résolution. Les scans planifiés et les alertes permettent de maintenir ce suivi lorsque le projet évolue.

Utilisez les tests automatisés pour rechercher des accès inattendus, puis la revue manuelle pour vérifier l’intention de chaque règle signalée. Le test montre ce qui est autorisé dans un contexte donné ; vous déterminez si cette autorisation est souhaitée.

Un score décrit uniquement le périmètre testé. Il aide à orienter les vérifications, sans certifier qu’un projet est entièrement sécurisé.

Si vous développez un produit Supabase sans avoir vérifié ses règles, combinez les deux approches. Commencez par des tests pour obtenir des observations concrètes, examinez ensuite les règles concernées et corrigez les écarts. Programmez de nouveaux contrôles pour suivre l’ajout de tables et l’évolution des autorisations.

Omettre l’une des deux approches peut laisser une règle apparemment protectrice autoriser malgré tout un accès indésirable.

Lancez un scan gratuit sur vice-platform.com pour vérifier votre site public avant l’inscription. Un scan spécialisé Supabase nécessite un domaine validé et un abonnement payant ou un crédit acheté. Sa couverture dépend des accès configurés.