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.
Partie 01
🛡️ 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.
Partie 02
🧐 Ê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).
Partie 03
🛠️ 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
GRANTexacte à copier-coller pour corriger le problème.
Partie 04
📅 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.
Partie 05
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.