Le cabinet de cybersécurité UpGuard a publié le 25 septembre 2026 une étude sur les bases de données hébergées par Supabase. Sur environ 300 000 domaines qui utilisent ce service, ses chercheurs ont identifié 16 326 bases dont au moins une table pouvait être lue sans authentification. Plus de la moitié présentaient des indices de données personnelles. UpGuard la présente comme la plus vaste étude de ce type à ce jour.
Un service devenu central pour les applications générées par IA
Supabase propose une base PostgreSQL hébergée, avec authentification et API prêtes à l’emploi. Ce n’est pas un produit d’IA, mais il est devenu l’une des briques les plus utilisées par les applications construites avec des agents de code. UpGuard le décrit comme la base de données la plus recommandée par Claude Code, en renvoyant aux mesures publiées par Amplifying. La société a atteint une valorisation de 10 milliards de dollars en juin 2026.
Le problème n’est pas nouveau. En mars 2025, le développeur Matt Turner avait signalé des bases mal configurées créées par la plateforme Lovable, une faille référencée CVE-2025-48757. Dans sa forme la plus simple, aucune règle n’empêchait un visiteur d’interroger la base. D’autres travaux ont suivi : Modern Pentest a trouvé des données personnelles exposées chez 28 % des 107 startups Y Combinator qu’il a testées, Escape a relevé 175 bases fuyantes sur environ 1 400 applications, et Wiz a découvert en février 2026 que la base du réseau social pour agents Moltbook exposait 35 000 adresses email et 1,5 million de jetons d’API.
La méthode : partir des domaines plutôt que des plateformes
Les études précédentes partaient souvent des sous-domaines de Lovable ou de Replit. UpGuard a voulu inclure les sites déployés sur leur propre nom de domaine, notamment ceux produits avec Claude Code ou Codex. Les chercheurs ont repéré l’usage de Supabase grâce aux adresses de bases et aux noms de clés présents dans le JavaScript public, en s’appuyant sur BuiltWith et sur le jeu de données Chrome UX Report.
Pour chacun des quelque 300 000 domaines, ils ont interrogé une table « users ». Trois réponses étaient possibles : un refus, une page de résultats, ou l’indication d’une autre table accessible, que Supabase renvoie comme suggestion lorsque le nom demandé n’existe pas. Pour éviter de lire chaque ligne, l’analyse a porté sur les schémas des tables. Le choix de la table « users » oriente mécaniquement les résultats vers les données personnelles, ce que le rapport reconnaît.
Ce que contenaient certaines bases
UpGuard a examiné quelques cas où les métadonnées laissaient présager une exposition importante, et dit avoir prévenu les propriétaires concernés :
- une plateforme indienne de contenus pour adultes : 65 467 utilisateurs avec pièces d’identité, comptes de versement et plus de 100 000 messages privés ;
- un service de valet aux États-Unis : plus de 100 000 clients, dont environ 78 000 plaques d’immatriculation, avec historique des visites et pourboires ;
- le consulat d’un gouvernement africain : 25 000 personnes avec leur adresse, dont certaines en hébergement d’urgence ;
- un service d’accompagnement à l’immigration au Canada : près de 5 000 fiches, dont 884 avec un mot de passe stocké en clair ;
- une ferme de cartes SIM aux Philippines servant à recevoir des codes de vérification : plus de 100 000 SMS.
Le type d’activité ne change pas le profil de risque, selon l’étude. Qu’un site vise des particuliers ou des entreprises, les réglages de sécurité sont les mêmes, parce que les personnes qui l’exploitent ne connaissent pas la configuration de leur base. Les fuites sont réparties sur tous les continents, avec une gravité moindre en Europe, ce qu’UpGuard attribue aux règles de protection des données.
Le point technique : la sécurité au niveau des lignes
La protection repose sur la Row Level Security (RLS) de PostgreSQL, qui filtre ce que chaque utilisateur peut lire. Supabase l’active désormais par défaut pour les tables créées dans l’interface graphique. D’après UpGuard, ce n’est pas le cas des tables créées par programme via l’API, qui est précisément le canal qu’utilisent les agents de code. Activer la RLS ne suffit d’ailleurs pas : les règles doivent être correctement écrites, et la clé publique ne doit pas être utilisée comme si elle était secrète.
Le rapport compare la situation à celle des compartiments Amazon S3 et des dépôts GitHub publics par défaut, deux produits dont les réglages permissifs ont alimenté des milliers de fuites avant d’être durcis.
La réponse de Supabase
Interrogé par TechCrunch, le responsable de la sécurité de Supabase, Bil Harmer, a indiqué ne pas avoir vu l’étude et affirmé que les projets sont « sécurisés par défaut ». Il décrit une responsabilité partagée : l’entreprise fournit des réglages et des outils sûrs, les clients contrôlent la configuration de leurs projets, et Supabase prévient ceux qui sont touchés lorsqu’un problème est détecté.
L’étude laisse plusieurs points ouverts. Le nombre de bases réellement consultées par des tiers n’est pas connu, et l’analyse par schéma indique la présence probable de données sensibles sans en mesurer le volume exact. UpGuard précise enfin que sa méthode pourrait être relancée ou élargie, et qu’elle trouverait sans doute davantage de bases exposées.
Pour passer de l’actualité à l’usage concret dans ton travail, la formation pour apprendre à faire travailler l’IA commence par une partie gratuite complète.