Sans aucun identifiant, les chercheurs d’UpGuard ont pu lire le contenu de 16 326 bases de données hébergées chez Supabase, dont plus de la moitié contenaient des données personnelles. Ils mettent en cause des applications conçues par des agents de code IA.
Supabase fournit aux développeurs la base de données et l’authentification de leurs applications web, avec une plateforme open source bâtie sur PostgreSQL. D’après UpGuard, Supabase est la base de données la plus recommandée par Claude Code, et plus de 60 % de ses nouvelles bases sont créées avec l’aide de l'IA, relève BleepingComputer. « Le point commun de ces sites est d’avoir été créés par des agents de code IA, sans que les humains aient conscience de leur configuration », ont résumé les chercheurs d’UpGuard. Microsoft a d’ailleurs reconnu que ses équipes ne suivaient plus le rythme des extensions nées du vibe coding soumises à son store Edge. Quand un créateur laisse une table Supabase mal réglée, n’importe quel internaute peut en lire le contenu, comme des pièces d’identité et messages privés.
Des tables Supabase créées sans protection par les agents de code IA
En mars 2025, le développeur Matt Turner a signalé une mauvaise configuration à grande échelle des bases Supabase créées avec l’outil de création d’applications par IA Lovable. Cette faille est répertoriée sous la référence CVE-2025-48757. D’après la société de tests d’intrusion Modern Pentest, 28 % des 107 start-up de l’incubateur Y Combinator bâties avec Lovable exposaient elles aussi des données personnelles.
Dans ces bases, la Row Level Security (RLS) de PostgreSQL était désactivée. Avec ce mécanisme, le développeur définit quelles lignes d’une table chaque utilisateur a le droit de lire ou de modifier. Sans lui, toute personne munie de la clé publique de l’application peut interroger ses tables, et n’importe quel visiteur peut récupérer cette clé dans le code JavaScript de la page. Supabase a ensuite activé la RLS par défaut pour les tables créées dans son éditeur graphique, mais pas pour celles créées par programmation, via l’API. Et c’est justement par cette voie que les agents de code IA, Claude Code et Codex d’OpenAI en tête, construisent leurs bases.
Pour mesurer l’étendue des dégâts, l’équipe de Greg Pollock, directeur de la recherche d’UpGuard, a recensé environ 300 000 domaines liés à Supabase, grâce au service d’analyse de sites BuiltWith et aux fichiers JavaScript du Chrome UX Report de Google. Ses chercheurs ont ensuite tenté de lire une table « users » sur chacun de ces domaines, et ont pu consulter des tables sur 16 326 bases. Dans une partie des cas, les développeurs avaient bien activé la RLS, mais avec des règles mal rédigées, ou avaient traité la clé publique en clé secrète.
Des pièces d’identité et des codes SMS en accès libre dans les bases Supabase
Plus de la moitié des bases exposées contenaient des données personnelles, et une part plus réduite des mots de passe ou des jetons d’authentification, indique UpGuard. Chez une plateforme indienne de contenus payants inspirée d'OnlyFans, les chercheurs ont eu accès aux données de 65 467 utilisateurs, avec des numéros de passeport et de permis de conduire, ainsi qu’à plus de 100 000 messages privés. Aux Philippines, un service d’envoi de codes à usage unique laissait lire plus de 100 000 SMS, codes de connexion compris. Un service d’immigration canadien stockait même 884 mots de passe en clair, sur environ 5 000 fiches. Chez un consulat africain, les données de 25 000 personnes ont été exposées ainsi que les lieux d’hébergement d’urgence.
Les sites de commerce en ligne et les restaurants sont les plus touchés par l’exposition de données de paiement, tandis que les sites de paris en ligne sans licence exposent le plus d’identifiants de connexion. Les développeurs européens ont de meilleures pratiques, sous l’effet des lois de protection des données, alors que les fuites sont plus nombreuses dans les pays en développement, observent les chercheurs.
UpGuard a prévenu les propriétaires des applications les plus exposées, sans faire état d’une réponse de Supabase. Pour Greg Pollock, la plateforme est « conçue pour que les agents de code IA puissent l’utiliser facilement », mais elle n’est « pas le premier produit à privilégier la commodité, au prix de mauvaises configurations chez l’utilisateur final ». Les utilisateurs de Supabase peuvent vérifier leurs tables avec les conseillers de sécurité intégrés à la plateforme et avec son guide de sécurisation de l’API. Le 25 septembre, date de publication du rapport, les tables créées via l’API de Supabase n’avaient toujours pas la RLS activée par défaut.
La Row Level Security (RLS) est un mécanisme de PostgreSQL qui permet de restreindre l’accès aux données “ligne par ligne”, selon l’utilisateur ou le rôle qui exécute la requête. Concrètement, elle sert à empêcher qu’un utilisateur authentifié (ou un service) puisse lire ou modifier des enregistrements qui ne lui appartiennent pas. Si la RLS est désactivée, une table peut devenir lisible “par défaut” dès lors que les permissions SQL ou la couche applicative laissent passer la requête. Dans un modèle comme Supabase, cela peut ouvrir la porte à des lectures non autorisées via l’API si les règles d’accès ne compensent pas l’absence de RLS. La sécurité dépend alors entièrement d’autres contrôles (policies, rôles, logique serveur), plus faciles à mal configurer.
Dans Supabase, la clé dite “publique” (souvent la clé anon) est destinée à être utilisée côté client, par exemple dans le JavaScript d’une application web. Elle n’est pas secrète : un visiteur peut la retrouver dans le code livré au navigateur. Cette clé n’accorde normalement qu’un accès limité, à condition que les politiques de sécurité (RLS et permissions) soient correctement en place. Si la RLS est absente ou mal écrite, cette clé peut devenir un sésame permettant d’interroger des tables qui auraient dû être filtrées par utilisateur. Le problème n’est donc pas la présence de la clé dans le front-end, mais l’absence de garde-fous serveur solides derrière.
Créer une table via l’éditeur graphique (console) et la créer “par programmation” via l’API ou des scripts n’emprunte pas exactement les mêmes chemins de configuration initiale. Selon les plateformes, les paramètres de sécurité par défaut (comme l’activation automatique de la RLS) peuvent être appliqués dans l’interface, mais pas dans les flux API, notamment pour rester compatibles avec des usages automatisés. Les agents de code IA et les outils de génération ont tendance à privilégier l’API (ou des migrations SQL) pour tout automatiser, ce qui augmente la probabilité de passer à côté d’un réglage attendu. Résultat : deux tables créées dans le même projet peuvent avoir des protections différentes selon la méthode de création. Pour éviter ça, il faut standardiser des templates/migrations qui activent explicitement la RLS et définir des policies dès la création.
