Scanner RLS Supabase : détecter les tables avec sécurité au niveau des lignes absente ou défaillante

Ce qu'un scan RLS externe peut prouver

A passive RLS scan looks at your Supabase project the way an anonymous visitor would. It uses only the publishable anon key — the same key your browser uses — and never authenticates as a user or touches service-role privileges. Anything it can see, an unauthenticated attacker on the internet can see.

Depuis l'extérieur de la base de données, un scanner peut confirmer ce qui suit avec un haut niveau de confiance :

• RLS est désactivé sur une table. PostgREST retourne des lignes pour un SELECT anonyme lorsque RLS est désactivé ou lorsqu'une politique le permet. Les deux cas constituent un résultat.
• Le rôle anonyme peut lister les tables. Un GET /rest/v1/ avec la clé anon retourne le schéma OpenAPI pour chaque table sur laquelle le rôle anon a un quelconque privilège. Les applications générées par IA accordent fréquemment USAGE sur le schéma et SELECT sur chaque table, ce qui expose la carte complète du schéma même lorsque RLS refuse les lectures réelles.
• Read access does not establish write safety. A passive scan cannot prove that INSERT, UPDATE, or DELETE policies protect every user and tenant. Review write policies and test them with isolated fixtures under the intended roles.
• La clé de rôle de service est dans le bundle du navigateur. Adjacent à RLS : si un scanner trouve SUPABASE_SERVICE_ROLE_KEY ou tout JWT avec role: service_role dans le bundle JavaScript, RLS est sans objet — le détenteur de cette clé contourne toute politique.

Ce qu'un scan externe ne peut pas prouver

Soyez honnête sur les limites du scanner. Un scan RLS externe ne peut pas lire votre table pg_policies, vos fichiers de migration ni le prédicat exact d'une politique. Il déduit du comportement en boîte noire, ce qui signifie qu'il signalera parfois un résultat qui s'avère être des données publiques intentionnelles (une table de newsletter marketing, un catalogue produit public). Le rapport FixVibe les marque comme confiance moyenne lorsque le scanner ne peut pas désambiguïser l'intention — examinez le nom de la table et décidez.

Les quatre formes de RLS défaillante que produisent les outils IA

When you point Cursor, Claude Code, Lovable, or Bolt at Supabase, the same four broken-RLS patterns come up again and again. Each one passes type-check, compiles, and ships:

Forme 1 : RLS jamais activé

The most common failure mode. The migration creates the table but the developer (or the AI tool) forgets ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST happily serves the entire table to anyone with the anon key. Fix: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;, then add a policy per command. Enabling RLS with no policies denies all access through the API; the policies decide who gets in.

ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;

Forme 2 : RLS activé, pas de politiques

Un échec plus subtil. RLS est activé mais aucune politique n'est écrite. Le défaut dans PostgreSQL est refuser, donc les utilisateurs authentifiés ne voient rien — et le développeur ajoute USING (true) pour faire fonctionner l'application, ce qui permet à tout le monde de tout lire. Correction : écrivez une politique qui limite par auth.uid() : CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); et une politique INSERT/UPDATE/DELETE correspondante.

CREATE POLICY "select_own"
  ON public.[name]
  FOR SELECT
  USING (auth.uid() = user_id);

Forme 3 : la politique compare la colonne à elle-même

Un artefact de copier-coller. Le développeur écrit USING (user_id = user_id) — qui est toujours vrai — au lieu de USING (auth.uid() = user_id). La vérification de types passe ; la politique autorise chaque ligne. Correction : comparez toujours une colonne à un appel de fonction (auth.uid(), auth.jwt()->>'org_id', etc.), jamais à elle-même ou à une constante.

Shape 4: Overly permissive write policies

With RLS enabled, a role with no applicable policy is denied by default. A SELECT policy does not itself allow INSERT. Write exposure can arise from a permissive applicable INSERT or ALL policy, disabled RLS, or a role that bypasses RLS. Fix: inspect table privileges and every applicable policy, use ownership-scoped WITH CHECK conditions, and test writes with separate user identities.

Comment fonctionne le scanner RLS Supabase de FixVibe

FixVibe's Supabase check works from the deployed app, in three steps:

1. Find the project. FixVibe loads the deployed app and reads the Supabase project URL and public key from the same configuration your browser receives. No guessing, no brute force.
2. See what is exposed. FixVibe checks which tables the anonymous role can see, without reading row data at this step.
3. Stage 3 — inspect anonymous read access. The passive check reports observable access to discovered resources. It does not create, update, or delete database rows, and it cannot establish that all write policies or cross-user boundaries are correct.

Each finding ships with the exact request URL, response status, response shape (header-only), and the table name. FixVibe now labels whether the fix belongs in code/config, a provider console, DNS, secret rotation, or manual review so the next step matches who can actually apply it.

Que faire quand le scanner trouve quelque chose

Chaque résultat RLS est une urgence en production. Les endpoints PostgREST publics sont scannés par des attaquants en quelques minutes. La séquence de remédiation est mécanique :

1. Auditez chaque table. Exécutez SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; dans l'éditeur SQL Supabase. Toute ligne avec rowsecurity = false est un problème.
2. Enable RLS on every public table. Default to ENABLE ROW LEVEL SECURITY on every table created — make it a migration template.
3. Rédigez des politiques commande par commande. N'utilisez pas FOR ALL USING (true). Rédigez des politiques explicites pour SELECT, INSERT, UPDATE, DELETE — chacune limitée à auth.uid() ou à une colonne d'org-id depuis auth.jwt().
4. Vérifiez avec un second compte. Inscrivez-vous en tant qu'autre utilisateur, tentez de lire les enregistrements d'un autre utilisateur via l'API REST directement. Si la réponse est 200, la politique est cassée.
5. Re-scan. After applying the fix, re-run a FixVibe scan against the same URL. The Supabase RLS finding should clear.

-- Audit every table for missing RLS. Run in the Supabase SQL editor.
SELECT schemaname, tablename, rowsecurity
FROM   pg_tables
WHERE  schemaname = 'public'
ORDER  BY rowsecurity, tablename;

Comment cela se compare aux autres scanners

La plupart des outils DAST génériques (Burp Suite, OWASP ZAP, Nessus) ne savent pas ce qu'est PostgREST. Ils parcourront votre application, ignoreront le chemin /rest/v1/ et rapporteront sur les pages HTML qu'ils comprennent. Snyk et Semgrep sont des outils d'analyse statique — ils trouvent des fichiers de migration dans votre repo avec des appels RLS manquants, mais ne peuvent pas prouver que la base de données déployée est mal configurée. FixVibe occupe ce vide : passif, conscient du BaaS, axé sur ce qu'un attaquant non authentifié peut prouver depuis l'URL publique.

Questions fréquentes

Étapes suivantes

Run a free FixVibe scan against your production URL — the Supabase RLS check runs on every plan including the free tier. For a deeper read on what else can leak from a Supabase project, see Supabase service role key exposed in JavaScript and Supabase storage bucket security checklist. For the umbrella view across all BaaS providers, read BaaS misconfiguration scanner.