FixVibe
Covered by FixVibehigh

Accès non autorisé aux données via une sécurité de niveau de ligne Supabase manquante (RLS)

Dans les applications basées sur Supabase, la sécurité des données repose sur la sécurité au niveau des lignes (RLS). Si RLS n'est pas explicitement activé et configuré avec des stratégies, tout utilisateur disposant de la clé publique anonyme peut lire, mettre à jour ou supprimer des données dans l'ensemble de la base de données. Ceci est particulièrement critique dans les environnements Next.js où le client Supabase est souvent initialisé avec une clé publique API.

CWE-284

##Impact L'échec de la mise en œuvre de la sécurité au niveau des lignes (RLS) permet à des attaquants non authentifiés d'interroger des données à partir d'une base de données Supabase lorsque des tables publiques sont exposées via la limite anonyme [S1]. Étant donné que les applications Next.js exposent généralement la clé Supabase anon dans le code côté client, un attaquant peut utiliser cette clé pour effectuer des appels REST API directs à la base de données, en contournant la logique d'application prévue et en accédant aux informations utilisateur sensibles [S2].

Cause première

Par défaut, les tables Postgres dans Supabase nécessitent l'activation explicite de la sécurité au niveau des lignes pour empêcher l'accès public à [S1]. Lorsqu'un développeur crée une table mais oublie d'activer RLS ou ne parvient pas à définir des stratégies restrictives, la base de données peut exposer les données à toute personne possédant la clé anon du projet [S1]. Dans les applications Next.js, le rendu côté serveur et la récupération côté client nécessitent également une configuration minutieuse du client Supabase afin que le contexte utilisateur authentifié atteigne la couche de base de données [S2].

Réparations concrètes

  • Activez RLS : Exécutez ALTER TABLE "your_table_name" ENABLE ROW LEVEL SECURITY; pour chaque table publique qui stocke les données d'application [S1].
  • Définir des stratégies : Créez des stratégies spécifiques qui restreignent l'accès en fonction du statut d'authentification de l'utilisateur, telles que CREATE POLICY "Users can see their own data" ON your_table_name FOR SELECT USING (auth.uid() = user_id); [S1].
  • Clients sécurisés côté serveur : Lorsque vous utilisez Next.js, conservez les clients de rôle de service uniquement sur le serveur et appliquez toujours des filtres de propriété avant de renvoyer les données aux utilisateurs [S2].

Comment FixVibe le teste

FixVibe exécute déjà une vérification Supabase RLS en lecture seule via baas.supabase-rls. Le scanner découvre l'URL du projet Supabase et la clé anonyme publique à partir des ensembles JavaScript de même origine, demande à PostgREST les métadonnées de la table publique et tente des sélections limitées en lecture seule pour confirmer si les données sont exposées sans session utilisateur. Il n'insère, ne met pas à jour, ne supprime ni n'utilise les informations d'identification du rôle de service. Les analyses de dépôt peuvent également détecter cela plus tôt via repo.supabase.missing-rls, qui signale les migrations SQL qui créent des tables publiques sans ENABLE ROW LEVEL SECURITY.