Supabase : Pourquoi vos nouvelles tables ne seront plus visibles (et comment corriger cela)

À partir du 30 mai 2026, Supabase renforce sa politique de sécurité. Le schéma « public » ne sera plus exposé automatiquement par défaut. Voici ce que vous devez savoir pour préparer vos projets.

Dans le monde du développement "Backend-as-a-Service", la facilité d'utilisation s'est souvent faite au détriment d'une sécurité stricte dès le premier jour. Supabase a décidé de corriger le tir en adoptant une approche "Secure by Default". Ce changement majeur modifie la manière dont PostgREST (le moteur derrière l'API de données) interagit avec vos tables.

🛡️ Le changement : La fin de l'exposition automatique

Jusqu'à présent, créer une table dans le schéma public de votre base de données signifiait qu'elle était immédiatement accessible via supabase-js, GraphQL ou des appels HTTP directs.

Après le 30 mai 2026, cette porte se ferme. Toute nouvelle table créée ne sera plus visible par l'API tant qu'une autorisation explicite (GRANT) n'aura pas été accordée.

🧐 Êtes-vous concerné ?

Vous êtes impacté si...Vous n'êtes PAS impacté si...Votre application utilise supabase-js ou les bibliothèques clientes.Vous vous connectez uniquement via une chaîne de connexion directe (ORM, serveur d'app).Vos scripts de migration créent des tables sans instructions GRANT.Vos tables existent déjà (les droits actuels sont conservés).Vous utilisez l'API REST (/rest/v1/) ou GraphQL (/graphql/v1/).Vos projets sont créés après le 30 octobre (la règle sera déjà en place).

🛠️ Guide pratique : Comment exposer vos tables désormais

Si vous souhaitez qu'une table soit accessible via l'API, vous devez inclure des autorisations explicites dans votre processus de création. Voici le nouveau standard à suivre dans vos fichiers SQL :

1. Accorder l'accès par rôle (GRANT)

C'est la nouvelle étape obligatoire. Sans cela, l'API ne "verra" même pas la table.

SQL

-- Pour les utilisateurs non connectés (accès public)
GRANT SELECT ON public.ma_table TO anon;

-- Pour les utilisateurs connectés (CRUD complet)
GRANT SELECT, INSERT, UPDATE, DELETE ON public.ma_table TO authenticated;

-- Pour les fonctions internes (service role)
GRANT ALL ON public.ma_table TO service_role;

2. Activer la sécurité au niveau des lignes (RLS)

Le GRANT ouvre la porte de la table, mais la RLS définit ce que l'on peut voir à l'intérieur.

SQL

ALTER TABLE public.ma_table ENABLE ROW LEVEL SECURITY;

-- Exemple : l'utilisateur ne lit que ses propres données
CREATE POLICY "Les utilisateurs lisent leurs lignes" 
ON public.ma_table 
FOR SELECT TO authenticated 
USING (auth.uid() = user_id);

Astuce d'expert : Si vous oubliez cette étape, PostgREST renverra une erreur 42501. La bonne nouvelle ? Le message d'erreur contiendra l'instruction GRANT exacte à copier-coller pour corriger le problème.

📅 Le calendrier à retenir

Notez bien ces deux dates charnières dans votre roadmap :

• 30 mai 2026 : Application par défaut pour tous les nouveaux projets.

• 30 octobre 2026 : Application généralisée à tous les projets existants.

Conclusion

Ce changement peut paraître contraignant, mais il s'agit d'une avancée majeure pour éviter les fuites de données accidentelles. En intégrant les instructions GRANT directement dans vos migrations, vous garantissez une architecture robuste et professionnelle.

Pour plus de détails techniques, vous pouvez consulter la discussion officielle sur le GitHub de Supabase.