Aller au contenu principal

RLS Supabase

Statut​

Document de cadrage sécurité — version initiale.

Définition​

La RLS, ou Row Level Security, est un mécanisme PostgreSQL utilisé par Supabase pour filtrer les lignes accessibles selon l'utilisateur et les policies SQL.

Dans DMV, elle doit être documentée comme un sujet de transition : utile historiquement, mais à rationaliser avec la cible Laravel centrale.

État actuel visible​

Le workspace contient des migrations Supabase avec des policies RLS dans :

  • dmv_backoffice/supabase/migrations ;
  • dmv-public/supabase/migrations.

Les migrations visibles couvrent notamment :

  • user_acteurs ;
  • profiles ;
  • users_roles ;
  • acteurs ;
  • publications ;
  • publication_reports ;
  • documents ;
  • feature_tabs et overrides ;
  • commune_infos, commune_elus, commune_collectes ;
  • contributor_favoris ;
  • app_settings ;
  • stats_events.

Des policies utilisent auth.uid(), des rôles admin, des rattachements acteur et parfois service_role.

Rôle actuel​

La RLS semble répondre à trois besoins historiques :

  • protéger les accès directs Supabase côté frontend ;
  • permettre certaines lectures publiques contrôlées ;
  • limiter les écritures à des propriétaires, admins ou services internes.

Cet état doit être traité avec prudence : il ne garantit pas à lui seul une autorisation métier complète si la logique applicative évolue côté Laravel.

Cible stratégique​

La cible DMV est que la logique métier sensible passe par Laravel.

Dans cette cible :

  • les frontends ne doivent pas contourner l'API pour les actions sensibles ;
  • les droits métier sont évalués dans les services, policies et middlewares backend ;
  • la RLS peut rester un garde-fou base de données si Supabase reste dans l'architecture ;
  • les policies SQL doivent être cohérentes avec les règles Laravel ;
  • les accès service_role doivent être très limités et jamais exposés côté client.

Bonnes pratiques​

  • Activer la RLS sur les tables exposées directement à Supabase.
  • Refuser par défaut, puis ouvrir explicitement.
  • Distinguer lecture publique, lecture propriétaire, écriture propriétaire et administration.
  • Éviter les policies trop larges ou difficiles à auditer.
  • Ne jamais utiliser service_role dans un frontend.
  • Tester les policies avec des comptes représentatifs.
  • Documenter chaque policy par domaine métier.

Risques​

RisqueImpact
Double logique Laravel/RLS divergenteDroits incohérents entre API et accès direct.
Accès frontend direct non maîtriséContournement possible des règles métier Laravel.
Policy SQL trop permissiveExposition de données privées.
Usage client du service roleCompromission majeure.
Absence de source canonique migrationsDifficulté à auditer et migrer.

Points à clarifier​

  • Rôle futur exact de Supabase : auth, base, storage, edge functions ou historique.
  • Tables encore exposées directement aux frontends.
  • Policies à conserver, supprimer ou convertir en garde-fous.
  • Stratégie de migration vers l'API Laravel centrale.
  • Processus de revue de sécurité des migrations SQL.