Supabase Row Level Security : 7 erreurs des applications créées par l'IA

Si votre application a été créée avec Lovable, Bolt ou un outil de création par IA similaire, il y a de fortes chances qu'elle utilise Supabase pour sa base de données et sa connexion. C'est un choix judicieux. Cela signifie aussi qu'un seul paramètre décide si les données de vos clients sont privées ou publiques : Row Level Security, généralement abrégé en RLS.

Des chercheurs en sécurité ont signalé publiquement en 2025 qu'un grand nombre d'applications générées par un outil de création par IA très populaire exposaient des données d'utilisateurs, car les politiques RLS étaient absentes ou trop faibles. Les applications fonctionnaient parfaitement lors des tests, car le créateur et le propriétaire pouvaient toujours tout voir. Le problème n'apparaît que lorsqu'un autre utilisateur, ou un attaquant, demande des données qui ne lui appartiennent pas.

Ce guide explique le RLS en termes simples, puis passe en revue les sept erreurs qui reviennent le plus souvent dans les projets Supabase générés par IA, avec la correction pour chacune.

Le RLS en langage clair

Supabase donne à votre frontend un accès direct à votre base de données via une API générée automatiquement. La clé « anon » livrée dans votre site web est publique par conception. N'importe qui peut la copier depuis le navigateur. Ce qui protège vos données, ce n'est pas la clé, ce sont les règles attachées à chaque table.

Row Level Security est ce règlement. Chaque règle (une policy) indique quelles lignes un type d'utilisateur donné peut lire, insérer, modifier ou supprimer. Une règle typique est « un utilisateur connecté peut lire les lignes où user_id est égal à son propre identifiant ». Si le RLS est désactivé pour une table, ou si les policies sont trop permissives, le règlement ne s'applique pas et l'API répondra à tout le monde.

Erreur 1 : le RLS n'a jamais été activé

Les tables créées via SQL ou des fichiers de migration ne sont pas protégées tant que vous n'y activez pas le RLS. Les outils d'IA créent souvent les tables, construisent les écrans, puis passent à autre chose. Tout fonctionne parce qu'il n'y a aucune restriction.

Pour vérifier, exécutez ceci dans l'éditeur SQL de Supabase et cherchez toute table du schéma public où rowsecurity vaut false :

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Activez-le avec une ligne par table, puis ajoutez des policies. Activer le RLS sans policy bloque tout, ce qui est le réglage par défaut le plus sûr pour construire :

alter table public.invoices enable row level security;

Le tableau de bord Supabase propose aussi un Security Advisor qui signale les tables sans RLS. Lancez-le avant chaque mise en production.

Erreur 2 : des policies qui autorisent tout

Lorsqu'un outil d'IA rencontre une erreur « permission denied », un raccourci courant consiste à écrire une policy comme using (true). L'erreur disparaît, et les données deviennent publiques en même temps.

-- Looks harmless, exposes every row to every user:
create policy "Allow read" on public.invoices
for select using (true);

Remplacez-la par une règle liée à l'utilisateur connecté :

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

Des données véritablement publiques, comme un catalogue de produits, peuvent utiliser une policy de lecture ouverte. Tout ce qui est personnel, financier ou privé ne le peut pas.

Erreur 3 : la clé de service est exposée

Supabase possède deux clés importantes. La clé anon est destinée aux navigateurs et repose sur le RLS. La clé service role contourne complètement le RLS. Si elle apparaît dans votre code frontend, dans une variable intégrée au bundle du site, ou dans un dépôt public, toutes les policies que vous avez écrites deviennent sans effet.

Recherchez-la dans votre JavaScript compilé et dans votre historique Git. Si elle a déjà été exposée, renouvelez-la immédiatement dans le tableau de bord Supabase. Les clés de service ne doivent se trouver que dans du code côté serveur, comme une edge function ou un backend, jamais dans quoi que ce soit que le navigateur télécharge.

Erreur 4 : des rôles stockés là où les utilisateurs peuvent les modifier

Un schéma fréquent consiste à marquer les administrateurs avec un champ tel que role: "admin" dans les métadonnées de l'utilisateur, puis à le vérifier dans une policy ou dans l'interface. Dans Supabase, la zone user_metadata peut être modifiée par l'utilisateur connecté. Un utilisateur peut tout simplement s'attribuer le statut d'administrateur.

Conservez les données d'autorisation dans des emplacements où les utilisateurs ne peuvent pas écrire : une table de rôles dédiée elle-même protégée par le RLS, ou le champ app_metadata contrôlé par le serveur. Fondez ensuite vos policies là-dessus.

Erreur 5 : des règles d'insertion et de mise à jour sans « with check »

Une policy peut contrôler quelles lignes existantes vous pouvez toucher (using) et quelles valeurs vous pouvez écrire (with check). Si la seconde partie est absente, un utilisateur peut insérer des lignes appartenant à quelqu'un d'autre, ou modifier sa propre ligne pour la transférer à un autre compte.

create policy "Users can insert their own invoices"
on public.invoices for insert
to authenticated
with check ( (select auth.uid()) = user_id );

create policy "Users can update their own invoices"
on public.invoices for update
to authenticated
using ( (select auth.uid()) = user_id )
with check ( (select auth.uid()) = user_id );

Erreur 6 : des vues et des fonctions qui contournent les règles

Une vue de base de données s'exécute par défaut avec les privilèges de son propriétaire, ce qui peut contourner le RLS des tables sous-jacentes. Dans Postgres 15 et versions ultérieures, vous pouvez faire en sorte qu'une vue respecte les permissions de l'appelant avec security_invoker = true. De même, une fonction marquée security definer et exposée à l'API s'exécute avec des droits élevés ; elle doit donc vérifier qui l'appelle et fixer son propre search_path.

Les vues et fonctions « utilitaires » générées par IA pour les tableaux de bord sont une source fréquente de ce problème. Passez-les en revue une à une et demandez-vous : avec quelles permissions s'exécute-t-elle ?

Erreur 7 : buckets de stockage et failles multi-locataires

Les fichiers ont leurs propres règles, distinctes de celles des tables. Un bucket public sert les fichiers à toute personne disposant du lien, ce qui convient pour des logos et pas pour des contrats. Pour les fichiers privés, organisez les téléversements par utilisateur ou par locataire et écrivez des policies de stockage correspondantes, par exemple en exigeant que le premier dossier du chemin soit égal à l'identifiant de l'utilisateur :

create policy "Users can read their own files"
on storage.objects for select
to authenticated
using (
  bucket_id = 'documents'
  and (storage.foldername(name))[1] = (select auth.uid()::text)
);

Pour les applications avec des équipes ou des organisations, chaque policy doit cibler le locataire via une table d'appartenance, et pas seulement l'utilisateur individuel. C'est aussi là que les policies écrites par IA deviennent le plus souvent incohérentes d'une table à l'autre.

Comment tester votre propre application en 15 minutes

1. Test anonyme. Appelez les endpoints de vos tables en utilisant uniquement la clé anon publique, sans connexion. Les tables privées doivent ne rien renvoyer ou renvoyer une erreur.
2. Test à deux comptes. Créez deux utilisateurs avec des données distinctes. En tant qu'utilisateur B, essayez de lire, modifier et supprimer les enregistrements de l'utilisateur A en changeant les identifiants dans les requêtes.
3. Test de privilèges. En tant qu'utilisateur normal, essayez directement les fonctions d'administration et essayez de modifier votre propre rôle.
4. Lancez le Security Advisor et corrigez chaque avertissement lié au RLS.
5. Conservez les tests. Supabase prend en charge les tests automatisés de base de données, de sorte qu'une modification future ne puisse pas rouvrir discrètement une faille.

Si vous avez déjà lancé votre application

Activez d'abord le RLS et corrigez les policies, puis renouvelez toutes les clés exposées. Examinez vos journaux à la recherche d'accès inhabituels. Si des données personnelles d'utilisateurs réels ont pu être exposées, vous pouvez avoir l'obligation légale de les en informer selon leur lieu de résidence ; consultez donc un avocat. Corriger les règles d'accès est généralement rapide. Déterminer ce qui s'est passé et ce qu'il faut divulguer prend plus de temps, ce qui est une raison de plus de détecter ces problèmes avant le lancement.

Vous ne savez pas où en est votre application ? Notre audit technique d'application IA examine vos policies, vos clés et votre stockage, et vous remet une liste de correctifs classés par priorité. Si vous savez déjà ce qui ne va pas, la réparation et mise en production d'applications IA couvre les corrections et une mise en production maîtrisée. Vous pouvez aussi commencer par la checklist de préparation à la production plus générale.