Supabase "permission denied for schema public" : trois causes

Hier, votre application marchait. Aujourd'hui, chaque écran qui lit des données dans Supabase s'affiche vide ou montre une erreur, et la console du navigateur affiche la même ligne pour chacun : permission denied for schema public. Vous ouvrez le tableau de bord Supabase, et toutes les tables sont toujours là. Le SQL Editor les lit sans la moindre plainte.

La réponse derrière cette ligne arrive le plus souvent sous forme de 401 ou de 403. Réduite aux deux champs qui comptent, elle dit ceci :

{
  "code": "42501",
  "message": "permission denied for schema public"
}

Supabase "permission denied for schema public" vient de Postgres, la base de données sur laquelle tourne Supabase, et la liste de ses causes est courte. Tout projet Supabase est créé avec un grant qui laisse votre application entrer dans le schéma public. Quelqu'un, ou quelque chose, l'a retiré, et le remettre tient en une ligne de SQL.

Voici la partie qu'il est facile de comprendre à l'envers : ce grant est la porte d'entrée du bâtiment, et les serrures qui protègent vos données sont plus loin à l'intérieur. Si quelqu'un l'a retiré pour garder les inconnus dehors, il a laissé votre application dehors avec eux. Et rouvrir cette porte n'est sûr que si ces serrures intérieures tiennent, donc ce sont elles qu'il faut vérifier avant de considérer le problème réglé.

Que signifie "permission denied for schema public" ?

Cela signifie que le rôle qui fait la requête n'a pas le droit d'entrer dans le schéma public, donc Postgres a refusé avant de regarder une seule table.

Un schéma est un dossier de tables nommé à l'intérieur de votre base de données. public est celui où Lovable, Bolt, v0, Cursor, Claude Code et Replit rangent vos tables si on ne leur dit rien d'autre. Un rôle est le type de visiteur dont vient une requête : anon est quelqu'un qui n'est pas connecté, authenticated quelqu'un qui l'est, et service_role votre propre code serveur qui utilise la clé secrète. Un grant donne à un rôle une permission sur une chose.

La permission dont parle cette erreur s'appelle USAGE, et la documentation de Postgres la décrit comme le droit de rechercher ("look up") des objets dans le schéma. Un rôle qui ne l'a pas n'atteint aucune table de ce schéma, quels que soient les réglages de la table elle-même.

Si la version table de cette erreur vous a appris à voir chaque table comme une pièce avec une porte par rôle, le schéma est le bâtiment qui contient ces pièces, et USAGE est sa porte d'entrée. permission denied for schema public signifie que votre requête attend dehors, devant cette porte. Peu importe quelles pièces ont leur porte ouverte, puisque la requête n'arrive jamais jusqu'à une pièce.

Supabase donne cette porte d'entrée aux trois rôles quand un projet est créé. L'image de base de données de Supabase exécute cette ligne dans son premier script d'installation :

grant usage on schema public to postgres, anon, authenticated, service_role;

Donc si votre application reçoit cette erreur, le grant a existé et il a disparu.

Pourquoi le SQL Editor marche-t-il encore ?

Parce que le SQL Editor n'utilise aucun des rôles de votre application. Un guide de dépannage de Supabase indique qu'une requête lancée depuis cet éditeur est "routed through the postgres role at the database level", c'est-à-dire qu'elle passe par le rôle postgres au niveau de la base de données.

postgres est le rôle propriétaire de vos tables, et si le schéma lui-même a été recréé depuis le tableau de bord ou par votre builder, il en est aussi propriétaire. Un propriétaire n'a besoin d'aucun grant pour entrer dans son propre bâtiment. Le tableau de bord affiche donc toutes les tables, un select dans le SQL Editor renvoie toutes les lignes, et la même requête envoyée par votre application est refoulée à la porte d'entrée. Rien sur ces écrans ne vous dit que les rôles de votre application ont perdu le chemin pour entrer.

Pour voir ce que voit votre application, interrogez Postgres directement sur ses rôles. Collez ceci dans le SQL Editor :

select rolname,
       has_schema_privilege(rolname, 'public', 'USAGE') as can_enter
from pg_roles
where rolname in ('anon', 'authenticated', 'service_role');

Chaque ligne devrait indiquer true. Une ligne qui indique false correspond à un rôle que votre application utilise et qui ne peut plus entrer.

Le grant ouvre le bâtiment, et les serrures sont à l'intérieur

USAGE permet à un rôle d'atteindre les tables d'un schéma. Il ne dit rien sur les tables que ce rôle peut utiliser, ni sur les lignes qu'il récupère.

Deux autres contrôles se trouvent derrière la porte d'entrée, et tous deux appartiennent à chaque table. Le grant propre à la table décide si un rôle peut utiliser cette table, et quand il manque, c'est ce que signale permission denied for table. Ensuite, Row Level Security, les règles par ligne que vous connaissez peut-être déjà, décide quelles lignes ce rôle récupère. Postgres pose les trois questions dans cet ordre et s'arrête au premier refus.

C'est cet ordre qui fait du grant sur le schéma une mauvaise serrure. Pour un rôle, c'est tout ou rien : retirez-le à anon, et chaque écran que voit un visiteur non connecté cesse de fonctionner d'un coup, y compris une page de connexion qui lit quoi que ce soit dans vos tables. Retirez-le à authenticated, et la même chose arrive à tous les visiteurs connectés. La documentation de Postgres ajoute que le révoquer "is not a completely secure way to prevent object access", autrement dit que ce n'est pas un moyen totalement sûr d'empêcher l'accès, et qu'un rôle qui ne l'a pas peut encore lire les noms de vos tables dans les catalogues système.

Si vous voyez cette erreur, votre application a besoin du rôle qui a été refusé.

Cause 1 : le schéma a été supprimé puis recréé

C'est la cause qui emporte le plus de choses avec elle. Quelqu'un a exécuté ces deux lignes, ou quelque chose qui fait la même chose :

drop schema public cascade;
create schema public;

La première ligne supprime le schéma et, à cause de cascade, chaque table, vue et fonction qu'il contenait. La seconde crée un nouveau public, vide. Un nouveau schéma appartient au rôle qui l'a créé, et la documentation de Postgres dit clairement que personne d'autre ne reçoit de privilège sur un schéma par défaut. Le grant que Supabase a exécuté à la création de votre projet appartenait à l'ancien schéma et il est parti avec lui, et Supabase n'exécute pas son script d'installation une seconde fois.

Ces deux lignes sont le moyen le plus court de vider une base Postgres, ce qui en fait une étape qu'un assistant IA peut choisir quand vous lui demandez de repartir de zéro ou de faire passer proprement une migration qui échoue.

Ensuite, vos tables reviennent si les migrations de l'application tournent à nouveau. Une migration est l'un des fichiers de changements de base de données que votre builder écrit, et les exécuter toutes reconstruit les tables qu'elles décrivent. Ce qui ne revient pas, c'est tout ce qu'elles ne mentionnent jamais, et le grant de la porte d'entrée a été créé par Supabase avant que votre première migration n'existe. Les migrations écrites par votre builder peuvent très bien ne pas le contenir du tout.

Deux autres choses partent avec l'ancien schéma :

• Les grants automatiques des nouvelles tables. Postgres les conserve comme privilèges par défaut (default privileges) du schéma, et ils sont supprimés avec lui. Les tables créées ensuite démarrent sans grant pour aucun des rôles de votre application.
• Les lignes. Les migrations reconstruisent des tables vides. Ce que contenaient les anciennes ne revient que si quelqu'un a restauré une copie faite avant la remise à zéro.

Si vos tables sont revenues vides, retrouver cette copie passe avant tout le reste de cette page.

Cause 2 : un revoke censé protéger

La deuxième façon est volontaire. Quelqu'un a lu que chaque table de public est accessible par la Data API de Supabase, l'adresse web par laquelle votre application lit et écrit ses données, et a révoqué le grant sur le schéma pour la fermer.

L'inquiétude de départ est raisonnable, et l'outil choisi est le mauvais. Le guide de Supabase pour sécuriser la Data API ne touche jamais au grant sur le schéma. Ce qu'il révoque, c'est l'accès automatique que reçoivent les nouvelles tables de public, pour que chaque nouvelle table reste fermée jusqu'à ce que quelqu'un lui donne accès volontairement. Supabase l'active pour tous les projets existants le 30 octobre 2026.

Si un script que vous avez lancé, ou un assistant à qui vous avez demandé de renforcer votre base, a retiré le grant sur le schéma, la requête de vérification ci-dessus montre quels rôles l'ont perdu. Rendez-le à ceux qu'utilise votre application, puis faites le renforcement comme le décrivent les sections suivantes.

Cause 3 : l'erreur vient d'une migration

Quand le message apparaît pendant que quelque chose crée des tables, par exemple une migration, un déploiement, ou Prisma ou Drizzle qui préparent votre base, la permission manquante est une autre. Créer quoi que ce soit dans un schéma demande CREATE sur ce schéma, et le texte de l'erreur quand CREATE manque est la même ligne.

Depuis Postgres 15, les rôles ordinaires ne reçoivent plus CREATE sur public par défaut. La documentation de Postgres précise que seules les bases mises à niveau depuis la version 14 ou plus ancienne le donnent encore à tout le monde. Un utilisateur de base de données à part, créé pour un outil de migration, est donc refusé dès sa toute première table. Le guide Prisma de Supabase crée un utilisateur prisma, et sa configuration comprend grant create on schema public to prisma.

La solution est un grant create pour ce seul utilisateur de migration. Personne qui visite votre application n'a besoin de créer des tables, donc anon et authenticated n'en reçoivent jamais.

Remettre le grant sans risque

Exécutez une ligne, vérifiez que les trois rôles peuvent entrer, puis rechargez votre application et lisez ce qu'elle dit ensuite.

La ligne, dans le SQL Editor :

grant usage on schema public to anon, authenticated, service_role;

Restez sur usage. grant all on schema public fait aussi disparaître l'erreur, et sur un schéma all veut dire usage plus create, le droit d'ajouter vos propres tables. Supabase conseille de donner à chaque rôle le minimum dont il a besoin, et les rôles de vos visiteurs ont seulement besoin d'entrer.

La requête de vérification de tout à l'heure devrait maintenant indiquer true pour les trois rôles. Rechargez votre application, et l'une de deux choses se produit :

• Elle fonctionne. La porte d'entrée était la seule chose qui manquait.
• Un nouveau message nomme une table. permission denied for table signifie que le grant propre à cette table manque aussi, ce qui est attendu après la première cause, puisque les tables reconstruites n'ont jamais reçu les grants automatiques. Donnez à chaque table son grant, Row Level Security et une règle en un seul changement.

Résistez à l'envie de donner tout sur toutes les tables à tous les rôles pour faire disparaître le second message. Une table avec un grant pour anon et Row Level Security désactivé donne toutes ses lignes à quiconque les demande, et rien dans votre application n'aura l'air différent.

Si le message nomme un autre schéma, comme permission denied for schema api, c'est un schéma que quelqu'un a créé, et il n'a jamais reçu les grants avec lesquels public démarre. Le guide de Supabase pour utiliser des schémas personnalisés donne les lignes dont il a besoin.

Ce qu'il faut verrouiller à la place

Les protections qui tiennent les inconnus à l'écart de vos données appartiennent à chaque table, et le guide de sécurité de Supabase les nomme :

1. Un grant par table, pour les rôles qui en ont besoin. Une table de commandes n'a besoin d'aucun grant pour anon.
2. Row Level Security sur chaque table, avec une règle.Comment l'activer, et vérifier qu'elle tient.
3. Les nouvelles tables fermées par défaut. Révoquer les grants automatiques le fait dès aujourd'hui, et le 30 octobre le fait pour vous.
4. Les tables internes hors de la Data API. Le guide de Supabase décrit le fait de mettre ce que lit votre application dans un schéma dédié, pour que tout le reste se trouve dans des schémas que la Data API ne sert pas.

Regardez ensuite le résultat depuis l'extérieur, car aucun de ces écrans ne montre ce qu'un inconnu récupère. Notre scan gratuit demande à chaque table que votre application nomme combien de lignes recevrait un visiteur non connecté, lit ce nombre sans récupérer une seule ligne, et prend environ 20 secondes, sans compte : scannez votre application.

Garder vos tables, et ce qu'elles contiennent

Après aujourd'hui, deux choses peuvent encore mal tourner : un changement ultérieur ouvre une table aux inconnus, et une remise à zéro comme dans la première cause emporte vos lignes.

Reeve Monitor continue de vérifier depuis l'extérieur :

• la vérification de sécurité complète toutes les heures, sur jusqu'à trois applications
• un message quand un résultat change, pour qu'une table ouverte après une migration n'attende pas que vous alliez voir
• si votre application répond
• un rapport mensuel, en langage clair, de ce qu'il a vu

Reeve Care garde une copie de ce que contiennent vos tables :

• une copie chiffrée de votre base de données Supabase selon un calendrier, sur le stockage propre de Reeve dans l'UE, en dehors de votre compte Supabase
• chaque copie vérifiée avant de compter, en comptant les lignes de chaque table
• vos fichiers envoyés aussi, dès que vous connectez un accès Storage
• une restauration en un clic, avec une copie de sécurité de l'état actuel prise d'abord
• tout ce que fait Monitor

Que faire maintenant

Commencez par la requête de vérification, car un seul résultat vous dit quels rôles de votre application ont perdu le chemin pour entrer. Puis, une fois la porte rouverte, scannez votre application pour voir ce qu'elle donne à un inconnu.