Le crochet
La sécurisation d'un projet Supabase nécessite une approche multicouche axée sur la gestion des clés API, la sécurité de la base de données et les autorisations de stockage. [S1] Une sécurité au niveau des lignes mal configurée (RLS) ou des clés sensibles exposées peuvent entraîner des incidents d'exposition de données importants. [S2] [S3]
Ce qui a changé
Cette recherche consolide les contrôles de sécurité de base pour les environnements Supabase sur la base des directives d'architecture officielles. [S1] Il se concentre sur la transition des configurations de développement par défaut vers des postures renforcées en production, en particulier en ce qui concerne les mécanismes de contrôle d'accès. [S2] [S3]
Qui est concerné
Les applications utilisant Supabase en tant que backend-as-a-service (BaaS) sont concernées, en particulier celles qui gèrent des données spécifiques à l'utilisateur ou des actifs privés. [S2] Les développeurs qui incluent la clé service_role dans les offres côté client ou qui ne parviennent pas à activer RLS courent un risque élevé. [S1]
Comment fonctionne le problème
Supabase exploite la sécurité au niveau des lignes de PostgreSQL pour restreindre l'accès aux données. [S2] Par défaut, si RLS n'est pas activé sur une table, tout utilisateur disposant de la clé anon, qui est souvent publique, peut accéder à tous les enregistrements. [S1] De même, le stockage Supabase nécessite des politiques explicites pour définir quels utilisateurs ou rôles peuvent effectuer des opérations sur les compartiments de fichiers. [S3]
Ce qu'obtient un attaquant
Un attaquant possédant une clé publique API peut exploiter les tables manquantes RLS pour lire, modifier ou supprimer des données appartenant à d'autres utilisateurs. [S1] [S2] L'accès non autorisé aux compartiments de stockage peut entraîner l'exposition de fichiers d'utilisateurs privés ou la suppression d'actifs d'application critiques. [S3]
Comment FixVibe le teste
FixVibe couvre désormais cela dans le cadre de ses contrôles Supabase. baas.supabase-security-checklist-backfill examine les métadonnées publiques du compartiment de stockage Supabase, l'exposition anonyme des listes d'objets, la dénomination sensible du compartiment et les signaux de stockage anonymes provenant de la limite publique anonyme. Les vérifications en direct associées inspectent l'exposition des clés de rôle de service, la posture Supabase REST/RLS et les migrations SQL du référentiel pour détecter les RLS manquants.
Que corriger
Activez toujours la sécurité au niveau des lignes sur les tables de base de données et implémentez des politiques granulaires pour les utilisateurs authentifiés. [S2] Assurez-vous que seule la clé « anon » est utilisée dans le code côté client, tandis que la clé « service_role » reste sur le serveur. [S1] Configurez le contrôle d'accès au stockage pour garantir que les compartiments de fichiers sont privés par défaut et que l'accès est accordé uniquement via des stratégies de sécurité définies. [S3]