Règles d'accès Supabase et Firebase (CWE-862) : comment l'absence de Row Level Security expose les données et comment corriger

Concepts Clés et Termes

Clé anon publique

La clé anon de Supabase et la configuration web de Firebase sont livrées dans le bundle de l'application, et n'importe qui peut les copier. Elles identifient le projet, pas l'utilisateur : ce ne sont pas des secrets et elles ne protègent pas les données à elles seules.

Row Level Security (RLS)

Une fonctionnalité de PostgreSQL qui filtre chaque requête à travers des politiques. Le Table Editor de Supabase l'active pour les nouvelles tables, mais les tables créées en SQL ou par migration démarrent sans RLS, et les droits par défaut laissent alors anon et authenticated lire et modifier toutes les lignes.

USING et WITH CHECK

USING détermine quelles lignes existantes un utilisateur peut voir, modifier ou supprimer ; WITH CHECK détermine quelles lignes nouvelles ou modifiées il peut écrire. Une politique n'ayant que USING sur insert ou update permet d'écrire des lignes pour une autre organisation.

Clé service_role

La clé service_role contourne entièrement la RLS. Elle n'a sa place que sur des serveurs et dans des edge functions, jamais dans un navigateur ou une application mobile.

Règles Firestore en mode test

Les projets démarrés en mode test reçoivent des règles qui autorisent toutes les lectures et écritures jusqu'à une date, et beaucoup finissent en allow read, write: if true. Les règles doivent comparer request.auth.uid au champ propriétaire du document.

Déroulement de l'Attaque Étape par Étape

Code Source : Vulnérable vs Sécurisé

-- migration.sql : la RLS n'est jamais activée sur cette table
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- la clé anon publique peut lire, modifier et supprimer toutes les lignes
grant select, insert, update, delete on public.invoices to anon, authenticated;

-- migration.sql : RLS activée, anon révoqué, une politique par commande
create table public.invoices (
  id bigint generated always as identity primary key,
  org_id uuid not null references public.orgs (id),
  customer text not null,
  amount_cents bigint not null
);

-- une fois la RLS activée, sans politique il n'y a aucun accès
alter table public.invoices enable row level security;
revoke all on public.invoices from anon;

-- les utilisateurs ne voient que les factures de leurs organisations
create policy "members read their org's invoices"
  on public.invoices for select to authenticated
  using (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

-- les nouvelles lignes doivent appartenir à une organisation de l'utilisateur ; pas de politique update ni delete
create policy "members add invoices to their org"
  on public.invoices for insert to authenticated
  with check (org_id in (select org_id from public.memberships where user_id = (select auth.uid())));

Liste de Contrôle de Sécurité pour l'Ingénierie

• Activez la RLS sur chaque table des schémas exposés, et faites échouer la CI quand select tablename from pg_tables where schemaname = 'public' and not rowsecurity renvoie une ligne.
• Écrivez une politique par commande, limitée to authenticated, avec USING pour les lectures et WITH CHECK pour les insertions et mises à jour ; n'ajoutez pas de politiques update ou delete inutiles.
• Retirez les droits de la table à anon quand les utilisateurs anonymes n'ont aucune raison de lire, et gardez la clé service_role uniquement dans les environnements serveur.
• Activez la RLS sur les tables que lisent vos politiques, comme memberships, pour que les utilisateurs ne puissent pas s'ajouter à une autre organisation.
• Testez avec deux utilisateurs de test : l'utilisateur A doit obtenir zéro ligne pour l'organisation de l'utilisateur B ; pour Firestore, exécutez des tests unitaires de règles sur l'émulateur avec @firebase/rules-unit-testing.

Sources

• CWE-862: Missing Authorization
• Supabase docs — Row Level Security
• PostgreSQL docs — CREATE POLICY
• Firebase docs — Get started with Cloud Firestore Security Rules
• NVD — CVE-2025-48757 (missing Row Level Security in generated apps)