"Infinite recursion detected in policy" sans désactiver RLS

Vous avez activé Row Level Security, écrit une règle pour que les admins voient tous les profils et que chacun ne voie que le sien, et maintenant plus un seul écran de votre app ne se charge. Chaque lecture revient avec la même ligne :

infinite recursion detected in policy for relation "profiles"

La plupart des réponses que vous trouverez disent la même chose, et c'est la mauvaise : désactivez Row Level Security sur cette table le temps de comprendre. L'erreur cesse effectivement. Ce qui la fait cesser, c'est que la table est désormais lisible par quiconque visite votre site.

Ce que signifie "infinite recursion detected in policy for relation"

Une règle posée sur une table a dû lire cette même table avant de pouvoir répondre.

Imaginez un portier qui vérifie chaque visiteur sur une liste d'invités, et la liste est rangée à l'intérieur de la salle qu'il garde. Pour lire la liste, il doit entrer. Pour entrer, il doit vérifier la liste. Il n'y a pas de premier pas, alors il reste dans le couloir et personne n'avance.

C'est ce qui est arrivé à votre base. On lui a demandé quelques lignes de profiles, elle est allée voir la règle sur profiles pour savoir lesquelles vous aviez le droit de voir, et la règle lui a dit d'aller voir dans profiles. Postgres s'aperçoit qu'il tourne en rond, abandonne et lève l'erreur avec le code 42P17 attaché. Supabase la transmet telle quelle à votre app, ce qui explique qu'elle se lise comme de la mécanique.

La requête échoue pour tous ceux à qui la règle s'applique, donc cela arrive en général comme une app entière qui reste vide d'un coup, et non comme un seul écran cassé.

Le cercle, dessiné

La règle qui provoque cela est celle que presque tout le monde écrit en premier, parce qu'elle dit exactement ce que vous voulez dire :

-- À rejeter : ceci lit profiles pour décider qui peut lire profiles.
create policy "admins read every profile" on profiles for select
to authenticated
using (
  exists (
    select 1 from profiles
    where id = (select auth.uid()) and role = 'admin'
  )
);

Le exists (select 1 from profiles …) est tout le problème. Lire profiles revient à appliquer la règle sur profiles, qui exécute à nouveau exists (select 1 from profiles …).

Le guide Row Level Security de Supabase nomme la version à deux tables : des policies sur deux tables qui lisent chacune l'autre ne se résolvent jamais, et la requête échoue pour chaque rôle auquel les policies s'appliquent. Une table qui se lit elle-même, c'est la même forme sans le détour.

Pourquoi est-ce toujours sur la table profiles ?

Parce que profiles est l'endroit où se trouve qui est cette personne.

Toute règle qui traite une catégorie de personnes autrement qu'une autre doit savoir à quelle catégorie appartient l'appelant, et cette information vit dans une colonne d'une table. Quel que soit le nom de cette table, la règle qui la protège finit par la lire. Dans une app faite avec Lovable, Bolt, v0 ou Replit, c'est en général profiles, parce que c'est là qu'atterrit la ligne de chaque personne connectée. Une règle sur des équipes, des organisations ou des documents partagés produit le même cercle sur la table qui porte l'appartenance.

La récursion vient donc du fait que vous avez écrit la règle évidente sur la seule table qui doit répondre à une question sur elle-même.

Le correctif : un helper qui lit la table en dehors des règles

Déplacez la question dans une petite fonction qui tourne en tant que propriétaire de la base, pour que lire profiles afin d'y répondre ne passe pas par la règle sur profiles.

create schema if not exists private;

create function private.is_admin()
returns boolean
language sql
security definer      -- tourne sous le rôle qui l'a créée
set search_path = ''  -- chaque nom à l'intérieur doit donc être écrit en entier
stable
as $$
  select exists (
    select 1 from public.profiles
    where id = (select auth.uid()) and role = 'admin'
  );
$$;

revoke execute on function private.is_admin() from public;
grant usage on schema private to authenticated;
grant execute on function private.is_admin() to authenticated;

-- La règle interroge maintenant la fonction au lieu de la table.
create policy "admins read every profile" on profiles for select
to authenticated
using ( (select private.is_admin()) );

Le portier a maintenant la liste d'invités sur une table dans le couloir. Il la lit sans ouvrir la porte, et la porte reste fermée pour tous ceux qui n'y figurent pas.

Quatre lignes font là-dedans un travail précis, et trois d'entre elles font la différence entre un correctif et un nouveau trou :

• security definer est ce qui rompt le cercle. Le guide de Supabase le définit comme une fonction qui tourne sous le même rôle que celui qui a créé la fonction, et sur Supabase ce rôle est postgres, qui a le droit de lire par-dessus les règles.
• set search_path = '' a sa place sur chacune d'elles. Supabase recommande de le poser sur toute fonction security definer et d'écrire les noms de tables en entier, car sans search_path épinglé un appelant peut faire pointer un nom non qualifié vers un objet qui lui appartient et le faire tourner avec les privilèges du propriétaire de la fonction. C'est pour cela que la fonction écrit public.profiles en entier.
• Le schéma private compte pour la même raison. Le guide de Supabase avertit qu'une fonction security definer posée dans un schéma exposé peut être appelée via la Data API avec les privilèges de son créateur, et vous dit de ne jamais en créer une dans un schéma listé sous Exposed schemas dans vos paramètres d'API.
• (select private.is_admin()), enveloppé dans un select à lui. Cela permet à Postgres de calculer la réponse une fois pour toute l'instruction au lieu d'une fois par ligne, ce que Supabase documente comme la raison d'envelopper auth.uid() de la même manière.

Les lignes revoke et grant gardent la fonction appelable par les utilisateurs connectés et par personne d'autre.

Cette policy couvre la lecture. Si l'enregistrement se met à échouer une fois que vos écrans se remplissent à nouveau, vous avez rencontré un autre message avec une autre cause.

Le correctif qui n'en est pas un

Désactiver Row Level Security sur profiles fait cesser l'erreur aussi, en un clic, et cela livre chaque ligne de cette table à quiconque possède la clé que votre app envoie au navigateur.

Cette clé est faite pour être publique. Elle est dans le code de votre site, et n'importe qui peut l'en extraire en quelques secondes. Ce qui l'empêchait jusque-là de renvoyer toute votre table d'utilisateurs, c'étaient les règles que vous venez de désactiver.

Votre app a la même tête ensuite dans les deux cas, et c'est ce qui rend la chose tenace. Rien sur vos écrans ne dit laquelle des deux vous avez choisie, et l'erreur a disparu dans les deux.

Ce qui le dit, c'est votre base, interrogée de l'extérieur. Nous avons scanné 31 056 apps en ligne faites avec Lovable, Bolt, v0, Replit et les autres, et vu un projet Supabase derrière 8 435 d'entre elles. Voici ce qu'a trouvé la vérification Row Level Security :

La ligne du milieu est la ligne honnête. Sur 4 755 de ces apps la vérification n'a obtenu aucune réponse, et nous le disons au lieu de les déclarer saines. Et certaines des 2 096 sont censées être lisibles, car une table publique est une chose qu'on peut vraiment vouloir ; de l'extérieur, un menu et une liste de membres se ressemblent.

Nous ne pouvons pas vous dire combien de ces tables ont été ouvertes par quelqu'un en train de faire disparaître exactement cette erreur. Nous pouvons vous dire qu'une table ouverte est l'état final ordinaire du conseil qui arrive en tête des résultats de recherche.

Si vous préférez ne pas avoir à y réfléchir, notre scan gratuit lit votre site en ligne et vous dit lesquelles de vos tables répondent à un inconnu. Il prend une vingtaine de secondes et ne demande aucun compte : scannez votre app.

Autre chose se produit quand vous le désactivez. L'advisor de Supabase se met à signaler la table, c'est l'avertissement RLS disabled in public, et il sera encore là dans un mois.

Comment savoir si le cercle a vraiment disparu

Le fait que l'erreur cesse n'est pas le test, car deux choses différentes la font cesser.

Il existe aussi une manière pour la fonction d'aide d'avoir l'air correcte et de continuer à tourner en rond, et Supabase la documente : une fonction security definer ne passe par-dessus les règles que si son propriétaire en a le droit. Sur Supabase le propriétaire est postgres, qui a ce privilège, donc le motif ci-dessus fonctionne. Une fonction appartenant à un rôle qui ne l'a pas, ou qui lit une table réglée sur force row level security, repasse par la règle et reste dans le cercle.

Deux vérifications, et faites les deux :

Écrivez les cas et faites-les tourner. La procédure de Supabase est un fichier .sql sous supabase/tests/ qui affirme autorisation et refus pour chaque opération, pour un utilisateur connecté et pour un anonyme, lancé avec supabase test db. Un admin doit voir tous les profils, un membre le sien, un inconnu rien. Tant que cela ne passe pas, tout ce que vous savez, c'est que l'erreur a cessé.

Puis demandez de l'extérieur, sans connexion. C'est la question que pose le navigateur d'un visiteur, et la seule qui reflète ce que votre app distribue vraiment. Si un inconnu peut lire votre base détaille la manœuvre, et Row Level Security peut être activé et la table rester publique traite le cas où les règles existent et laissent quand même tout le monde passer.

Quand la récursion vous dit que le schéma est faux

Parfois il n'y a pas de question circulaire à retirer, parce que les deux tables dépendent réellement l'une de l'autre.

Le guide de Supabase prend le partage comme exemple : une règle sur lists consulte list_members pour voir avec qui la liste a été partagée, et une règle sur list_members consulte lists pour voir à qui elle appartient. La règle de chaque table lit l'autre, et aucune ne peut passer en premier. Le même helper dénoue cela, avec une fonction qui renvoie les ids de listes auxquelles l'appelant appartient, et les deux règles qui interrogent cette fonction au lieu de s'interroger l'une l'autre.

Le signal qui mérite votre attention, c'est quand il vous en faut trois ou quatre pour qu'un schéma tienne. À ce stade, l'appartenance est reconstruite dans les règles à chaque fois, et une seule table qui dit clairement qui peut voir quoi demande en général moins d'entretien que les règles que vous êtes en train de démêler.

Garder la table fermée après l'avoir réparée

Une règle que vous avez réparée aujourd'hui décrit la base d'aujourd'hui. La prochaine policy, la prochaine table et la prochaine fois que quelqu'un fait disparaître une erreur à minuit arrivent toutes après votre dernier coup d'œil, et aucune ne change quoi que ce soit de visible sur vos écrans.

Reeve Monitor repose à votre app les mêmes questions, selon un calendrier :

• les neuf vérifications toutes les heures, sur trois apps au plus
• un message quand un résultat change, pour qu'une table ouverte cette nuit n'attende pas que vous le remarquiez
• si l'app répond, toutes les 60 secondes
• un rapport mensuel de ce qu'il a vu

Si votre app garde ses données dans votre propre projet Supabase, Reeve Care en conserve aussi une copie. Une règle qui laisse un inconnu lire est un problème. Une règle qui laisse un inconnu écrire en est un autre, et aucune vérification de cet article ne ramène des lignes supprimées.

• une copie chiffrée de votre base Supabase chaque nuit, gardée là où votre projet ne peut pas l'atteindre
• chaque copie vérifiée avant de compter, en comptant les lignes de chaque table
• une restauration en un clic quand vous en avez besoin
• vos fichiers téléversés aussi, dès que vous connectez un identifiant Storage
• tout ce que fait Monitor

Ce qu'il faut faire maintenant

Si vous voulez le reste de la liste pour une app tout juste lancée, la checklist de sécurité en 10 minutes couvre ceci et les autres points qu'il vaut mieux fermer avant que quelqu'un ne les trouve.