RLS Supabase en prod : quatre pièges qui silencent tes requêtes

« Tes inscriptions, il y en a combien ? Moi j'en vois zéro »

Un mardi matin, je venais d'activer RLS sur dix-huit tables de Rembrandt, l'ERP de L'Atelier Palissy. Les policies étaient écrites, testées en SQL direct, tout passait. Déploiement en prod, café. Françoise m'appelle du bureau d'à côté, elle ne vient pas, elle crie depuis sa chaise. « Bon. Tes inscriptions sur le site de Maisons-Laffitte, il y en a combien, dis-moi ? Moi j'en vois zéro. » J'ouvre la même page sur mon poste. Zéro aussi. Pas d'exception, pas de 500, pas de log d'erreur dans Sentry. Simplement zéro ligne, ce qui est précisément ce qui rend ce bug dangereux : Françoise ne voit rien à corriger, elle voit une école vide.

Row Level Security est une des rares features Postgres/Supabase qui peut casser ton application en silence. Un mauvais réglage ne te renvoie pas d'erreur. Il te renvoie un ensemble vide, ou pire, un ensemble partiel qui passe le code sans l'alerter. J'ai passé quatre semaines à tomber sur quatre pièges distincts, à les nommer, à les documenter. Cet article les rassemble.

---

Si tu as 30 secondes. RLS bien configurée est le meilleur garde-fou de données que tu puisses poser sur une base Supabase. RLS mal configurée est le pire bug parce qu'elle ne crie jamais. Les quatre pièges : mauvais client Supabase côté Server, RPC SECURITY DEFINER ouvertes à anon, policies d'écriture sans role check, bucket Storage public oublié. Chacun a un symptôme silencieux — requête vide, endpoint public, écriture autorisée, fichier exposé — et une correction en cinq minutes une fois la cause trouvée. L'article donne les quatre symptômes et les quatre corrections.

Piège 1 — Le mauvais client côté Server Component

C'est le piège qui a mis Françoise devant une école vide. Supabase expose trois clients distincts, et leur différence ne se voit pas au premier regard.

• createSupabaseBrowser() avec la anon key, côté navigateur
• createSupabaseServer() avec la anon key plus le cookie d'auth, côté Server Component
• createSupabaseAdmin() avec la service_role key, côté serveur, bypass RLS

Le piège : si tu utilises createSupabaseServer() dans un Server Component mais que le cookie d'auth ne transite pas correctement — middleware mal configuré, refresh token expiré, route proxy qui reforme la requête —, le JWT tombe à anon. Aucune policy ne matche pour un utilisateur anon. La requête retourne zéro ligne. Pas d'erreur, parce que techniquement la requête est valide, Postgres a juste trouvé que rien ne matche.

La règle que j'ai fini par écrire dans mon CLAUDE.md et dans un skill auto-invoqué par l'agent : dans un Server Component, utiliser createSupabaseAdmin(), jamais createSupabaseServer(). L'authentification est déjà vérifiée en amont par le middleware qui garde la route, la service_role n'atteint jamais le navigateur, et les requêtes retournent ce qu'elles doivent retourner.

// ❌ Silencieusement vide si l'auth ne passe pas
import { createSupabaseServer } from '@/lib/supabase-server'
const supabase = createSupabaseServer()
const { data } = await supabase.from('inscriptions').select('*')
// data = [] sans erreur

// ✅ L'auth est déjà vérifiée par le middleware, RLS bypassée
import { createSupabaseAdmin } from '@/lib/supabase-admin'
const admin = createSupabaseAdmin()
const { data } = await admin.from('inscriptions').select('*')

Piège 2 — Les fonctions RPC ouvertes à anon

Deuxième piège, plus vicieux parce qu'il te rend les données en sens inverse : tu n'as pas trop peu, tu as trop de monde qui peut lire.

Supabase génère des endpoints REST pour toutes tes fonctions Postgres déclarées en SECURITY DEFINER, et par défaut PUBLIC a les droits d'exécution. Or PUBLIC dans Postgres inclut le rôle anon, qui est le rôle utilisé quand quelqu'un tape un curl sur ton endpoint sans token. Autrement dit, tes fonctions de calcul — pay_echeance_tx, publier_planning_tx, convertir_sd_tx — sont exposées par défaut à n'importe qui sur internet.

J'ai découvert ça en auditant la surface publique avec la requête de contrôle suivante :

-- Liste les fonctions executables par anon (dangereux par défaut)
SELECT p.proname, n.nspname
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'public'
  AND has_function_privilege('anon', p.oid, 'EXECUTE');

Elle m'a sorti quinze fonctions que je n'avais jamais voulu exposer. Correction en bloc et ALTER DEFAULT PRIVILEGES pour que les futures fonctions héritent des bons droits :

-- Fermer toutes les fonctions existantes à anon
REVOKE EXECUTE ON ALL FUNCTIONS IN SCHEMA public FROM PUBLIC;
GRANT  EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO authenticated, service_role;

-- Que les futures fonctions héritent de la règle
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT  EXECUTE ON FUNCTIONS TO authenticated, service_role;

Les flux publics légitimes — formulaire d'inscription, signature d'émargement par QR code — transitent tous par des API routes Next.js qui utilisent la service_role. Révoquer anon n'a rien cassé. Ce qui aurait dû être le comportement par défaut, et qui ne l'est pas.

Piège 3 — Les policies d'écriture sans role check

Troisième piège. Tu actives RLS sur une table, tu écris une policy SELECT qui dit que tout utilisateur authentifié peut lire. Tu oublies d'écrire la policy INSERT / UPDATE / DELETE, et Supabase fait le pire choix possible : il autorise, parce qu'en Postgres, sans policy d'écriture explicite, la table est ouverte à tout rôle qui a le droit Postgres de base.

Autrement dit, n'importe quel utilisateur authentifié peut écrire dans n'importe quelle table dont tu n'as posé que la policy de lecture. Un élève qui a un compte peut insérer une ligne dans contrats_formateurs. Il ne le fera pas, mais il pourrait, et le jour où un compte est compromis, le périmètre d'attaque est toute ta base.

Le pattern que j'applique désormais sur toute nouvelle table : une policy SELECT pour staff+, une policy INSERT / UPDATE / DELETE pour admin+ seulement, avec role check explicite sur user_roles.

-- Lecture staff et au-dessus
CREATE POLICY "select_staff" ON contrats_formateurs
  FOR SELECT TO authenticated
  USING (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('staff', 'admin', 'super_admin')
    )
  );

-- Écriture admin uniquement
CREATE POLICY "write_admin" ON contrats_formateurs
  FOR ALL TO authenticated
  USING (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('admin', 'super_admin')
    )
  )
  WITH CHECK (
    EXISTS (
      SELECT 1 FROM user_roles
      WHERE email = auth.email()
        AND role IN ('admin', 'super_admin')
    )
  );

Le WITH CHECK est la moitié qu'on oublie toujours. Sans lui, un utilisateur autorisé à écrire peut écrire une ligne qu'il ne serait pas autorisé à lire ensuite. C'est un classique des audits RLS : la politique de lecture et la politique d'écriture doivent converger, ou le système devient incohérent.

Piège 4 — Le bucket Storage public oublié

Dernier piège, celui qui fait les gros titres quand il fuite. Tu crées un bucket Supabase Storage pour stocker des signatures manuscrites, des pièces justificatives, des photos d'identité — bref, des données soumises au RGPD. Par défaut, le bucket est public. Tu as probablement posé RLS sur tes tables, tu es fier, tu oublies que les fichiers vivent à côté, avec leurs propres règles.

Concrètement : n'importe qui connaissant l'URL d'un fichier peut le télécharger, et l'URL est parfois traçable, devinable, ou exposée dans un path enregistré en clair dans une colonne de ta base. J'ai mis trois semaines à m'en apercevoir. La correction tient en deux étapes.

Étape 1 : passer le bucket en privé via le dashboard Supabase, ou par migration :

UPDATE storage.buckets
SET public = false
WHERE name = 'signatures';

Étape 2 : côté code, ne plus utiliser getPublicUrl() mais stocker le path et servir le fichier via une API route authentifiée qui vérifie la permission et retourne un signed URL expirant en cinq minutes.

// ❌ URL publique, valable pour toujours, indexable
const { data } = supabase.storage
  .from('signatures')
  .getPublicUrl(path)

// ✅ Signed URL expirant, après vérification de permission
const { data } = await supabaseAdmin.storage
  .from('signatures')
  .createSignedUrl(path, 60 * 5)  // 5 minutes

Le cinquième piège, en bonus, celui qu'on ne voit pas venir

Il y en a un autre, plus rare mais spectaculaire quand il se déclenche : la récursion infinie sur les policies user_roles. Si ta policy sur user_roles utilise elle-même un EXISTS (SELECT 1 FROM user_roles...) pour vérifier le rôle, tu as créé une boucle : lire user_roles appelle la policy qui lit user_roles qui appelle la policy. Postgres te renvoie une erreur infinite recursion detected in policy, et toutes les requêtes qui passent par cette table échouent.

La parade : la policy user_roles ne peut pas référencer user_roles. Elle doit être formulée sur auth.email() directement, ou contourner via une SECURITY DEFINER, ou — ce que j'ai fait pendant plusieurs semaines avant de trouver mieux — laisser la table accessible en read-only à tout authentifié et protéger l'écriture ailleurs.

Ce que tu peux copier dans ton projet

Quatre réflexes directement applicables :

1. Audit de la surface anon — la requête SQL ci-dessus sort en trente secondes la liste des fonctions exposées. Si tu n'as jamais fait cet audit, fais-le aujourd'hui
2. createSupabaseAdmin() par défaut côté Server Component — l'auth est déjà vérifiée en amont par ton middleware. Le client SSR avec anon key est une usine à requêtes vides silencieuses
3. Un couple USING + WITH CHECK sur chaque policy d'écriture. Pas de politique d'écriture sans check. Pas de politique de lecture sans politique d'écriture
4. Un script de diff qui liste les tables avec RLS activée mais sans *policies* — c'est un piège classique à la création d'une nouvelle table, et le meilleur moment de le corriger est tout de suite

Et une discipline plus large : un système de permissions qui ne crie pas quand il échoue est un système dangereux. RLS est puissante parce qu'elle est invisible, et c'est aussi pour ça qu'elle te coûtera cher. Instrumente-la : audite la surface anon mensuellement, logue les requêtes qui reviennent vides sur des pages censées être peuplées, alerte quand un bucket change de visibilité.

Et vous, votre dernière requête qui renvoyait zéro ligne en prod, c'était vraiment zéro ligne, ou RLS qui la filtrait en silence ? Je lis les commentaires.

---

Code compagnon : rembrandt-samples/rls-supabase/ — l'audit de surface anon, le couple SELECT + WRITE avec WITH CHECK, le pattern user_roles sans récursion, la migration de privatisation Storage, le guide de sélection de client, et le détecteur RLS-sans-policies. Licence MIT.