Supabase : 16 000 bases exposées, le vibe coding en cause

Ce qui s'est passé

La firme de cybersécurité américaine UpGuard a publié fin septembre 2026 les résultats d'une analyse à grande échelle portant sur les configurations de sécurité des applications utilisant Supabase, la plateforme open-source de base de données-as-a-service fondée sur PostgreSQL. En analysant environ 300 000 domaines intégrant Supabase, les chercheurs ont découvert que plus de 16 000 d'entre eux exposent publiquement des tables de bases de données contenant des données sensibles — sans aucune authentification requise pour y accéder. Cette exposition résulte de configurations incorrectes des politiques de sécurité au niveau des lignes (Row-Level Security, RLS) et d'une utilisation inappropriée des clés publiques.

L'ampleur des données exposées est significative. Les chercheurs d'UpGuard ont confirmé des fuites réelles affectant des services en Inde, aux Philippines, aux États-Unis, en Afrique et au Canada. Parmi les incidents documentés, un service de voiturier américain a exposé plus de 100 000 dossiers clients, incluant noms, adresses, numéros de téléphone et informations sur les véhicules. Plus préoccupant encore, un service d'immigration canadien a exposé près de 5 000 comptes utilisateurs avec leurs mots de passe stockés en clair — une pratique qui viole non seulement les bonnes pratiques de sécurité, mais aussi les exigences légales de la loi canadienne sur la protection des renseignements personnels (LPRPDE). Des tokens d'authentification permettant l'accès direct aux comptes ont également été exposés dans plusieurs cas.

Le vecteur principal de ces expositions est ce qu'UpGuard et la communauté de développeurs désignent sous le terme « vibe coding ». Ce concept, popularisé par le chercheur en IA Andrej Karpathy début 2025, décrit une pratique de développement où le développeur délègue l'intégralité de l'écriture du code à des agents IA — Cursor, GitHub Copilot, Claude Code, ou d'autres assistants — sans nécessairement comprendre le code produit ni valider sa conformité aux bonnes pratiques de sécurité. L'agent IA génère un schéma de base de données fonctionnel, des APIs et une interface utilisateur, mais ne configure pas systématiquement les politiques RLS ni ne vérifie que les tables contenant des données sensibles ne sont pas accessibles publiquement via la clé anonyme Supabase.

Supabase utilise deux types de clés API : la clé anonyme (anon key), destinée à l'accès public depuis le navigateur, et la clé de service (service_role key), qui bypasse toutes les politiques de sécurité et ne doit jamais être exposée côté client. Dans les applications mal configurées analysées par UpGuard, la clé anonyme donne accès direct à des tables qui n'auraient dû être accessibles qu'aux utilisateurs authentifiés ou aux administrateurs. Ce problème est documenté dans la documentation officielle de Supabase depuis le lancement de la plateforme, mais les agents IA qui génèrent du code Supabase ne configurent pas systématiquement les politiques RLS sur chaque table sensible.

La réalité de la chaîne de création est révélatrice : l'agent IA crée la table, insère quelques lignes d'exemple, génère l'API et passe à la suite. La politique RLS reste désactivée par défaut sur Supabase jusqu'à ce que le développeur l'active explicitement. Un développeur expérimenté vérifie ce point ; un développeur utilisant le vibe coding pour la première fois, se fiant entièrement à l'agent IA pour valider la sécurité, passe très facilement à côté. UpGuard souligne que Supabase lui-même a introduit de nouvelles alertes dans son tableau de bord pour signaler les tables sans politiques RLS, mais ces alertes ne sont pas rétroactives et ne s'affichent pas dans les interfaces des outils de développement IA tiers.

Parmi les types de données exposées recensées par UpGuard, on trouve : informations d'identification personnelle (noms, adresses, dates de naissance, numéros de téléphone), mots de passe en clair ou faiblement hachés, tokens JWT et tokens de session actifs, clés API internes, données de localisation, informations médicales dans certains cas, et dans au moins un cas, des données partielles de cartes bancaires. La gravité varie considérablement selon les applications, mais la combinaison token d'authentification actif + données PII représente le scénario le plus dangereux car elle permet une prise de contrôle directe des comptes utilisateurs sans exploiter de vulnérabilité logicielle.

La réponse de Supabase a été rapide mais limitée. La plateforme a publié une mise à jour de sa documentation soulignant l'importance des politiques RLS et renforcé les avertissements dans son interface d'administration. Toutefois, UpGuard souligne que ces mesures ne corrigent pas automatiquement les applications déjà déployées, et que les outils de développement tiers qui génèrent du code Supabase n'intègrent pas encore systématiquement de vérification des politiques de sécurité dans leur workflow. En l'absence d'une correction automatique côté plateforme, la responsabilité reste entière sur les développeurs.

Du côté des victimes, la situation est particulièrement préoccupante car beaucoup ignorent probablement que leurs données sont accessibles publiquement. Contrairement à une violation par exploitation d'une vulnérabilité — qui laisse des traces dans les logs —, un accès à une table Supabase sans RLS via la clé anonyme est techniquement légitime du point de vue de la plateforme. Il n'y a aucune alerte, aucun incident de sécurité enregistré, aucun comportement anormal à détecter. Les données peuvent être exfiltrées silencieusement et indéfiniment sans que l'opérateur de la base en soit jamais informé.

Pourquoi c'est important

Cette découverte d'UpGuard soulève une question fondamentale sur la maturité sécurité de l'écosystème du développement assisté par IA. Le vibe coding a explosé en 2025-2026, porté par des outils comme Cursor, Bolt, Replit et GitHub Copilot Workspace. Ces outils permettent à des personnes sans formation technique approfondie de créer des applications fonctionnelles en quelques heures. L'enjeu n'est pas la fonctionnalité — ces applications fonctionnent — mais leur posture de sécurité. Des études internes chez plusieurs éditeurs de sécurité montrent que les applications générées par IA présentent en moyenne un taux de misconfiguration de sécurité significativement plus élevé que les applications écrites manuellement par des développeurs expérimentés.

Pour les responsables de la sécurité des systèmes d'information (RSSI) en entreprise, ce phénomène crée un nouveau risque : des applications shadow IT créées par des employés via des agents IA, hébergeant des données d'entreprise sur des instances Supabase non supervisées, sans politique de sécurité. Le périmètre de contrôle s'étend désormais bien au-delà des applications officiellement déployées. Le RGPD, applicable en France et dans toute l'Union européenne, impose aux responsables du traitement des données une obligation de sécurité : une base de données exposant des données personnelles sans contrôle d'accès constitue une violation caractérisée qui peut déclencher une notification obligatoire à la CNIL et exposer l'organisation à des amendes pouvant atteindre 4 % du chiffre d'affaires mondial.

L'incident Supabase s'inscrit dans un pattern plus large de risques liés à la démocratisation du développement via l'IA. En 2025, des études similaires avaient révélé des milliers de clés API et tokens d'authentification exposés dans du code généré par GitHub Copilot. En 2026, c'est la couche données qui est concernée. Le maillon faible n'est pas l'IA elle-même, mais le manque de guardrails de sécurité dans le workflow de déploiement : absence de scan de sécurité avant mise en production, absence de revue de code par un pair, absence de vérification des configurations cloud dans le pipeline CI/CD.

La réglementation européenne NIS2, pleinement en vigueur depuis octobre 2024, impose aux entreprises des secteurs essentiels de mettre en œuvre des mesures de gestion des risques de cybersécurité couvrant leur chaîne d'approvisionnement logicielle. L'utilisation non supervisée d'agents IA pour créer des applications manipulant des données sensibles entre dans le périmètre de ces obligations. Les DSI et RSSI sont invités à établir une politique claire sur l'utilisation des outils de développement IA, incluant une revue de sécurité obligatoire avant tout déploiement de base de données, quelle que soit la méthode de développement utilisée.

Ce qu'il faut retenir

• 16 000 bases Supabase exposent publiquement des données PII, mots de passe et tokens : le vibe coding sans revue de sécurité est directement en cause, les politiques RLS étant désactivées par défaut.
• Vérifiez immédiatement vos projets Supabase : dans le tableau de bord, section Authentication > Policies, chaque table sensible doit avoir des politiques RLS actives et explicites.
• Le RGPD s'applique : une base exposée contenant des données personnelles impose une notification à la CNIL dans les 72 heures suivant la découverte de l'exposition.