Comment exposer du contenu public avec Supabase sans ouvrir vos donnees privees

Un blog, un CMS ou des pages marketing ont besoin de contenu public. C'est normal. Le probleme arrive quand une equipe ouvre trop large la base pour servir ce contenu, alors que seules quelques tables devraient etre lisibles sans connexion.

Avec Supabase, vous pouvez exposer du contenu public proprement. Mais il faut separer le besoin marketing du modele de securite. Sinon, vous finissez avec une base qui "marche", mais qui donne trop d'acces.

Le besoin legitime

Dans beaucoup de projets, il faut que des visiteurs non connectes puissent lire :

• des articles de blog
• des pages de contenu CMS
• des fiches publiques
• des donnees d'affichage tres ciblees

Cela ne veut pas dire que anon doit pouvoir toucher toutes les tables public.

Le bon raisonnement est : quelles donnees doivent etre lisibles publiquement, et rien de plus ?

La mauvaise solution

La mauvaise solution consiste a donner des droits larges a anon sur tout le schema public, parce que c'est plus rapide.

Le probleme de cette approche :

• vous melangez contenu public et donnees privees
• vous rendez l'audit plus difficile
• vous augmentez le risque d'oublier une table ouverte par erreur

Un schema public dans Postgres n'est pas synonyme de donnees publiques. C'est juste un schema nomme public.

La bonne logique

Pour exposer du contenu public proprement avec Supabase, il faut combiner :

1. des GRANT explicites
2. la RLS sur les tables exposees
3. des policies qui n'autorisent que ce qui doit etre lu

Exemple : vous avez une table public.blog_posts qui doit etre lisible publiquement, mais editable seulement par des utilisateurs autorises.

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

grant select on table public.blogposts to anon; grant select, insert, update, delete on table public.blogposts to authenticated; grant select, insert, update, delete on table public.blogposts to servicerole;

alter table public.blog_posts enable row level security;

create policy "public can read published posts" on public.blog_posts for select to anon using (status = 'published');

create policy "authenticated can read published posts" on public.blog_posts for select to authenticated using (status = 'published'); ```

Dans ce schema :

• anon ne peut lire que ce qui est explicitement public
• authenticated a plus de capacites si votre produit le demande
• service_role reste reserve au serveur

Pourquoi la RLS reste utile meme pour du public

Certaines equipes pensent qu'une table publique n'a pas besoin de RLS. En pratique, la RLS reste tres utile pour poser des limites lisibles.

Par exemple, vous pouvez rendre public :

• seulement les articles publies
• seulement les fiches validees
• seulement les contenus d'un certain type

Sans cette couche, vous pouvez exposer des brouillons, des contenus internes ou des donnees de travail sans le vouloir.

Une bonne separation de tables

Si vous avez un CMS un peu riche, la meilleure pratique consiste souvent a separer :

• les tables de contenu public
• les tables internes de gestion
• les tables metier privees

Par exemple :

• blog_posts : contenu public lisible
• cms_config : configuration interne, pas publique
• messages, invoices, clients : strictement prives

Cette separation rend les GRANT beaucoup plus faciles a comprendre.

Le cas tres frequent du site marketing

Un site marketing ou un site d'agence n'a en general besoin de anon que sur un perimetre tres limite :

• contenu de page
• articles publies
• quelques donnees de navigation ou de presentation

Tout le reste doit rester ferme.

Si vous donnez a anon un acces large "en attendant", cet "en attendant" devient souvent l'etat final.

Comment verifier que votre exposition publique est propre

Voici une petite checklist utile :

1. Listez toutes les tables auxquelles anon a acces.
2. Pour chaque table, demandez-vous si un visiteur externe doit vraiment la lire.
3. Verifiez que la RLS est activee sur chaque table exposee.
4. Verifiez que les policies limitent bien aux contenus publics ou publies.
5. Testez la lecture avec le vrai role anon, pas avec un compte admin.

Cette derniere etape est essentielle. Beaucoup de faux positifs viennent de tests faits avec trop de droits.

Ce qu'il faut faire pour les nouveaux projets Supabase

Depuis le changement de 2026 sur la Data API, il est encore plus important de formaliser l'exposition publique au moment de la migration.

Le schema sain devient :

• on cree la table
• on donne a service_role ce dont le serveur a besoin
• on donne a anon seulement select si le contenu doit etre public
• on active la RLS
• on ecrit une policy claire qui decrit ce qui est vraiment public

Cette methode evite a la fois la casse fonctionnelle et la sur-exposition.

Ce qu'il faut retenir

Exposer du contenu public avec Supabase est simple si vous gardez une regle claire : public ne veut pas dire tout le schema, seulement les donnees qui ont vraiment vocation a etre publiques.

Le bon modele repose sur des GRANT explicites, de la RLS, et des policies qui decrivent ce que le visiteur peut lire. C'est plus propre pour la securite, plus lisible pour l'equipe, et plus stable a mesure que le projet grandit.

Sources officielles

• Supabase - Securing your API
• Supabase - Row Level Security
• Supabase - Breaking Change: Tables not exposed to Data and GraphQL API automatically