Supabase : 16 326 bases de données laissent leurs tables lisibles, selon UpGuard
Le 24 septembre 2026, la société de cybersécurité UpGuard a publié une étude sur les bases de données hébergées chez Supabase : sur environ 300 000 domaines présentant des indices d'usage du service, elle en a identifié 16 326 dont des tables étaient lisibles depuis Internet. Plus de la moitié portaient des indices de données personnelles. Pour un DPO, le sujet n'est pas Supabase en soi : c'est la vague d'applications générées par des agents de code, qui arrivent chez les métiers et les sous-traitants sans passer par la case sécurité.
Ce qu'a trouvé UpGuard
UpGuard a repéré les sites utilisant Supabase à partir de données publiques (BuiltWith, Chrome UX Report), puis a interrogé chaque base sur une table « users ». Quand cette table n'existait pas, la base renvoyait elle-même le nom d'une table accessible. L'analyse a porté sur les schémas des tables, pas sur chaque ligne : plus de la moitié des 16 326 bases présentaient des indices de données personnelles, une part plus faible des mots de passe ou des jetons d'authentification, et un très petit nombre des données plausibles de carte bancaire.
UpGuard a examiné à la main quelques cas, et dit avoir prévenu les propriétaires des applications quand l'exposition était significative. Parmi eux :
- un service de voiturier du nord-est des États-Unis : plus de 100 000 clients avec leur numéro de téléphone, environ 78 000 plaques d'immatriculation, l'historique des visites, les pourboires et un champ de notes libres ; 4 560 des adresses e-mail exposées relèvent de domaines d'entreprises tierces ;
- le consulat d'un gouvernement africain, en France selon TechCrunch : 25 000 personnes avec leurs adresses, et un champ indiquant leur lieu d'hébergement d'urgence ;
- un service d'accompagnement à l'immigration vers le Canada : près de 5 000 comptes, dont 884 avec un mot de passe stocké en clair ;
- une plateforme indienne de contenus pour adultes : 65 467 utilisateurs, des champs de permis de conduire, de passeport et de comptes de paiement, et plus de 100 000 messages privés.
Pourquoi ces bases sont ouvertes
La cause décrite par UpGuard est une configuration, pas une faille du produit. Supabase active désormais la sécurité au niveau des lignes (RLS) par défaut pour les tables créées depuis son interface graphique, mais pas pour celles créées par l'API, qui est précisément la voie qu'empruntent les agents de code. Même activée, la RLS doit être correctement paramétrée ; parmi les autres causes relevées, des clés publiques utilisées dans le code côté client comme si elles étaient secrètes. Le problème est connu depuis mars 2025 et le signalement de bases mal configurées créées avec Lovable (CVE-2025-48757) ; ce qui manquait, selon UpGuard, c'était la mesure de son ampleur.
Dans l'article de TechCrunch du 25 septembre, le directeur de la sécurité de Supabase, Bil Harmer, indique que l'entreprise n'a pas vu l'étude, affirme que les projets sont sécurisés par défaut et décrit une responsabilité partagée : « We provide secure defaults and tooling, and customers control how their own projects are configured ».
Ce que dit le RGPD
Une table lisible par n'importe qui est exactement ce que l'article 25 du RGPD veut empêcher : par défaut, les données ne doivent pas être rendues accessibles à un nombre indéterminé de personnes. L'article 32 impose des mesures techniques et organisationnelles appropriées, et le contrôle d'accès à une base en est le premier étage. Le partage de responsabilité revendiqué par l'hébergeur ne change rien pour le responsable du traitement : la configuration de son projet lui revient. Et si l'application est éditée par un prestataire, c'est l'article 28 qui s'applique, avec l'obligation de ne recourir qu'à des sous-traitants présentant des garanties suffisantes.
Leto relevait déjà le même schéma avec les 9 300 clés AWS actives retrouvées en ligne par Truffle Security : le risque ne vient pas du cloud, il vient de ce que l'on y laisse ouvert.
Ce que ça change pour les organisations
- Recenser les applications construites par les métiers avec un agent de code ou une plateforme de « vibe coding », et les inscrire au registre si elles traitent des données personnelles.
- Pour chaque base Supabase, vérifier que la RLS est activée sur toutes les tables, y compris celles créées par script, et que seules des clés publiques figurent dans le code côté client.
- Ajouter la question à l'audit des sous-traitants : quelle base de données, qui la configure, quel contrôle d'accès, quel test avant mise en production.
- Si une table s'avère avoir été lisible, traiter l'épisode comme une violation de données : évaluer le risque, notifier la CNIL dans les 72 heures s'il existe, informer les personnes s'il est élevé.
Ce que Leto en pense
Les agents de code ont fait baisser le coût de création d'une application ; ils n'ont pas fait baisser le coût d'une fuite. Le bon réflexe n'est pas d'interdire ces outils, c'est de les faire entrer dans le quotidien du DPO : un registre à jour, une question de plus dans les audits, un test d'accès avant toute mise en ligne. Pour voir comment Leto outille ce suivi, une démo suffit.
Sources
