Supabase 42501 permission denied : un droit, pas la RLS

J’ai construit un audit de sécurité Supabase gratuit qui lit les droits de chaque table exposée, et 42501 est l’erreur qu’on rencontre quand les droits sont faux dans l’autre sens : trop peu au lieu de trop. Voici ce qu’elle signifie et ce que j’ai vu en la reproduisant.

Que signifie l’erreur 42501 dans Supabase ?

42501 est le code Postgres des privilèges insuffisants. Postgres vérifie deux couches avant qu’un client touche une table : les droits décident si le rôle peut exécuter l’opération, et les politiques RLS décident quelles lignes. Un droit manquant échoue en premier, sous forme d’erreur. Une politique qui ne correspond à rien échoue en silence, sous forme de liste vide. Quand vous voyez 42501, regardez donc les droits, pas vos politiques.

PostgREST, la Data API derrière supabase-js, transmet l’erreur avec un indice. Sur mon stack local (Supabase CLI 2.109.1, Postgres 17.6, PostgREST 14.14), une requête avec la publishable key vers une table sans droit pour anon a renvoyé HTTP 401 et :

{
  "code": "42501",
  "details": null,
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.orders TO anon;",
  "message": "permission denied for table orders"
}

Pourquoi les nouvelles tables renvoient-elles 42501 après le 30 octobre 2026 ?

Jusqu’ici, une nouvelle table de public recevait select, insert, update et delete pour anon, authenticated et service_role par les privilèges par défaut : elle était atteignable via la Data API dès sa création, protégée ou non. Le changelog de Supabase retire ces défauts : facultatif depuis le 28 avril 2026, par défaut pour les nouveaux projets depuis le 30 mai 2026, et appliqué à tous les projets existants le 30 octobre 2026. Les tables existantes gardent leurs droits.

Ce que le basculement casse d’autre et comment vérifier le projet avant : Supabase, changement des grants du 30 octobre : que vérifier.

J’ai appliqué le même changement à mon projet local avec les deux instructions alter default privileges … revoke du changelog, puis créé une nouvelle table invoices :

Requête vers la nouvelle table	Résultat
Publishable key, aucun droit	HTTP 401, 42501, indice GRANT SELECT ON public.invoices TO anon;
Secret key, aucun droit	HTTP 403, 42501, indice … TO service_role;
Publishable key, après grant select et enable row level security	HTTP 200, [] tant qu’une politique n’autorise pas de lignes

Deux choses m’ont surpris. La secret key est refusée aussi : service_role contourne la RLS, mais il lui faut quand même un droit, si bien qu’une Edge Function ou une tâche serveur qui écrit dans une nouvelle table casse de la même façon. Et le revoke ne reprend que ces quatre opérations : la nouvelle table est quand même arrivée avec REFERENCES, TRIGGER et TRUNCATE pour anon, authenticated et service_role. Aucune politique ne s’applique à TRUNCATE.

Comment corriger 42501 sans ouvrir la table ?

Traitez le droit, la RLS et la politique comme un seul changement, dans une seule migration, et n’accordez à chaque rôle que ce dont il a besoin :

revoke all on table public.invoices from anon, authenticated;
grant select, insert, update on table public.invoices to authenticated;
grant select, insert, update, delete on table public.invoices to service_role;

alter table public.invoices enable row level security;

create policy "Owners read their invoices"
on public.invoices for select
to authenticated
using ((select auth.uid()) = user_id);

Le revoke all du début retire d’abord TRUNCATE, TRIGGER et REFERENCES arrivés avec la table. Ne répondez pas à 42501 par grant all on all tables in schema public to anon : c’est l’ancien défaut qui revient, pour toutes les tables à la fois, et toute table sans RLS devient lisible par quiconque a votre clé publique.

Si un outil d’IA crée vos tables, dites-lui d’émettre les droits, la RLS et les politiques dans la même migration. L’indice de l’erreur est écrit pour qu’un agent puisse corriger le droit lui-même, mais il ne nomme que le droit, pas la RLS qui devrait l’accompagner.

Comment l’audit voit-il cela ?

Quatre de ses règles lisent la couche des droits : « Privilèges par défaut qui ouvrent les nouveaux objets à l’API » signale les projets qui accordent encore automatiquement les nouvelles tables, « Droits d’écriture inutilisés pour les visiteurs anonymes » trouve les droits d’écriture de anon qu’aucune politique n’utilise, et « Droits de table inutiles pour les utilisateurs connectés » trouve TRUNCATE, TRIGGER et REFERENCES comme ceux ci-dessus. « Politiques qui ne s’exécutent jamais : le rôle n’a pas le droit » liste les tables où une politique nomme un rôle sans droit pour cette commande, ce qui est l’allure d’une nouvelle table après le 30 octobre. Pourquoi la RLS compte encore après le droit se lit dans comment tester Supabase RLS, et à quoi ressemblent droits et politiques sur toute une application dans ma checklist de sécurité d’une application Lovable.