Erreurs RLS : le guide 2026 pour Supabase, PostgreSQL et les accès multi-tenant

Pourquoi ce cluster existe

RLS, pour Row Level Security, est devenu un mot-clé central dans les stacks modernes parce qu'il permet d'exposer une base ou une API de données tout en gardant une isolation fine entre utilisateurs, rôles ou tenants.

Le problème est simple : beaucoup d'équipes disent avoir "mis du RLS" alors qu'elles ont surtout activé une option, copié deux policies, ou déplacé la confiance vers un JWT, un rôle privilégié ou une fonction qui contourne l'intention initiale.

Les docs officielles PostgreSQL sont très claires. Sans policy, si un utilisateur a déjà les privilèges SQL nécessaires, toutes les lignes restent accessibles. Quand RLS est activé, tout accès normal doit être autorisé par une policy. Et s'il n'existe aucune policy, le comportement devient défaut-deny.

Erreur n°1 : croire qu'activer RLS suffit

Activer RLS est une étape. Ce n'est pas un modèle d'autorisation.

Sur Supabase, la recommandation officielle est explicite : les tables d'un schéma exposé doivent avoir RLS activé. Mais cela ne garantit pas que les policies sont bonnes. Une policy trop large ou mal pensée peut laisser passer exactement ce que vous vouliez empêcher.

Le faux sentiment de sécurité vient souvent de là : l'équipe sait que RLS est activé et conclut que le sujet est clos.

Erreur n°2 : protéger SELECT mais pas INSERT, UPDATE ou DELETE

PostgreSQL permet de définir des policies par commande. C'est puissant, mais cela crée un piège très classique : la lecture est bien cadrée, alors que la modification reste trop large.

En pratique, cela donne des cas comme :

C'est l'une des raisons pour lesquelles les erreurs RLS apparaissent souvent comme des bugs métiers avant d'être reconnues comme des vulnérabilités de sécurité.

Erreur n°3 : faire confiance aux mauvaises données du JWT

Les docs Supabase rappellent un point essentiel : les informations de raw_user_meta_data peuvent être modifiées par l'utilisateur authentifié. Ce n'est donc pas un bon endroit pour stocker des données d'autorisation.

Autre subtilité importante : un JWT n'est pas toujours frais. Une policy fondée sur des claims rarement rafraîchis peut continuer à prendre de mauvaises décisions alors même que le rôle réel a changé.

Autrement dit : si votre politique de sécurité repose sur des métadonnées fragiles ou périmées, votre RLS a l'air propre mais décide sur une base instable.

Erreur n°4 : oublier les rôles qui contournent RLS

Les docs PostgreSQL précisent que les superusers et les rôles BYPASSRLS contournent toujours le système. Les propriétaires de table le contournent aussi en général, sauf configuration spécifique.

Côté Supabase, la doc indique également que les service keys peuvent bypass RLS. Elles ne doivent jamais être exposées dans le navigateur ni confiées à une logique frontend.

C'est une erreur fréquente sur les apps livrées vite : la policy semble restrictive, mais un RPC, une Edge Function, un worker ou un script d'admin repasse en réalité par un rôle qui voit tout.

Erreur n°5 : croire que RLS couvre toute la surface

RLS protège des lignes. Il ne sécurise pas à lui seul :

C'est pour cela que Supabase RLS : 5 erreurs courantes doit être lu en parallèle d'un audit plus large de l'application, et pas comme une checklist autonome.

Les points à relier dans votre stack

Si vous utilisez Supabase ou PostgreSQL dans une architecture produit moderne, reliez toujours RLS à ces autres sujets :

Notre lecture

RLS est l'un des meilleurs mécanismes de défense en profondeur disponibles dans les stacks modernes. Mais il ne pardonne ni le flou métier, ni les rôles trop puissants, ni les raccourcis d'implémentation.

En 2026, la bonne question n'est pas "avez-vous activé RLS ?" La bonne question est : quelles policies décident réellement, pour quelles commandes, à partir de quelles données d'identité, et par quels chemins peut-on encore contourner cette logique ?