Outils / Actualités / UpGuard trouve 16 326 bases Supabase dont les tables sont lisibles par tous
Presse

UpGuard trouve 16 326 bases Supabase dont les tables sont lisibles par tous

· VaultTools

UpGuard a analysé environ 300 000 domaines utilisant Supabase et identifié 16 326 bases de données exposant des tables lisibles, dont plus de la moitié avec des indices de données personnelles. TechCrunch a rapporté l'étude le 25 septembre 2026. En cause : l'absence de sécurité au niveau des lignes, souvent dans des applications créées avec des agents de code IA.

VaultTools · 2 octobre 2026

Un écran d'ordinateur rempli de code source, le type de code applicatif généré qui peut être mis en ligne avec une base de données lisible par tous. Photo sur Unsplash

Table des matières

Ce qui s’est passé

L’entreprise de sécurité UpGuard a étudié des applications web construites sur Supabase, un service de base de données hébergé très utilisé par les petites équipes et les applications générées par IA. Des milliers d’entre elles laissent fuiter les données de leurs utilisateurs sur le web ouvert. Selon BleepingComputer, les chercheurs ont analysé environ 300 000 domaines à la recherche de signes d’utilisation de Supabase. UpGuard résume le résultat ainsi : « Across the candidate set we identified 16,326 databases exposing readable tables. »

TechCrunch, qui a rapporté l’étude le 25 septembre 2026, évoque environ 16 000 bases présentant un certain degré d’exposition de données personnelles. Personne ne s’est introduit nulle part. Les tables répondaient à des requêtes web ordinaires, parce que rien n’indiquait à la base de les refuser.

Ce qui a été exposé

« Over half of the databases had indicators of some PII », écrit UpGuard. Une part plus faible contenait des mots de passe ou des jetons d’authentification, et un très petit nombre ce qui ressemblait à des données de carte bancaire. Les cas individuels montrent ce que cela signifie concrètement :

  • Une plateforme de streaming pour adultes en Inde : 65 467 fiches d’utilisateurs, avec selon UpGuard des champs pour le permis de conduire et le passeport, ainsi que plus de 100 000 messages privés.
  • Un service de voiturier aux États-Unis : plus de 100 000 fiches clients avec coordonnées, plaques d’immatriculation et historique des visites.
  • Un consulat géré par un gouvernement africain : environ 25 000 fiches d’utilisateurs avec données personnelles et adresses, dont des lieux d’hébergement d’urgence.
  • Un service d’immigration canadien : près de 5 000 fiches d’utilisateurs, dont 884 avec des mots de passe en clair.
  • Un service d’OTP basé aux Philippines : les données de plus de 2 000 utilisateurs et 100 000 SMS, dont des codes à usage unique.

Ces entreprises n’ont rien en commun, sauf leur pile technique. Comme le formule UpGuard : « The security settings are invariant to business type because the humans, who know what kind of business they are advertising, do not understand their database’s configuration. »

Comment c’est arrivé

Avec Supabase, une application web dialogue avec sa base directement depuis le navigateur, à l’aide d’une clé publique intégrée à la page. Ce qui empêche un utilisateur de lire les lignes de tous les autres, ce sont les politiques de sécurité au niveau des lignes (RLS, row-level security). Si elles manquent, la clé publique suffit pour lire la table.

UpGuard situe précisément l’origine de la faille : « Supabase has made product changes to implement RLS by default for tables created in the Table Editor UI. Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default. » BleepingComputer cite comme causes des politiques RLS absentes ou inefficaces, un mauvais usage des clés publiques et des configurations de sécurité applicative insuffisantes.

La question de l’IA demande de la prudence. BleepingComputer note que plus de 60 % des bases Supabase nouvellement créées sont attribuées au développement assisté par IA, mais aussi que, de l’aveu même des chercheurs, leurs analyses « do not establish that every affected site was built using an AI coding agent ». Le propos plus général d’UpGuard porte sur les incitations. Selon le rapport, « data leaks are the multiplicative product of a technology’s ease of misconfiguration and the size of its user base ».

Supabase a déclaré à TechCrunch que les projets sont sécurisés par défaut et que la sécurité est une responsabilité partagée avec les clients. Son RSSI, Bil Harmer, a ajouté : « Security at Supabase is never finished. We care deeply about getting it right, and we’ll keep making it easier for every developer to ship securely. »

La chronologie de la divulgation

  • Mars 2025 : le développeur Matt Turner signale, selon UpGuard, des erreurs de configuration généralisées dans les bases Supabase créées par la plateforme de vibe coding Lovable.
  • 25 septembre 2026 : TechCrunch publie un article sur les conclusions d’UpGuard.
  • 28 septembre 2026 : BleepingComputer détaille la méthodologie et les cas individuels.
  • 1er octobre 2026 : date affichée sur le rapport complet d’UpGuard.

UpGuard indique avoir prévenu les propriétaires des applications « in the cases where we determined a significant exposure ». Le rapport ne dit pas quand, ni combien des 16 326 bases ont été verrouillées depuis.

Pourquoi c’est important pour les outils de fichiers dans le navigateur

Cette étude porte sur des tables de base de données, pas sur des fichiers téléversés. Le rapport d’UpGuard ne décrit ni documents exposés ni buckets de stockage, et il serait faux de prétendre le contraire. Le lien se situe un cran en amont : il s’agit de petites applications web, construites rapidement, dans lesquelles des utilisateurs ont saisi des données personnelles en faisant confiance à un backend qu’ils ne pouvaient pas inspecter. Un visiteur n’a aucun moyen de savoir si le site qu’il a sous les yeux fait partie des 16 326.

C’est exactement la situation de quiconque envoie un scan de passeport ou un contrat à un convertisseur en ligne inconnu. Le fichier arrive dans le stockage de quelqu’un d’autre, régi par des réglages que l’utilisateur ne verra jamais, écrits par un développeur (ou un agent de code) qui ne les comprend peut-être pas non plus.

Traiter un fichier entièrement dans le navigateur supprime cette dépendance. Quand un PDF est fusionné ou une image compressée en local via WebAssembly, il n’y a ni envoi, ni ligne dans une table, ni politique d’accès que quelqu’un doit configurer correctement. Un outil qui ne reçoit jamais les données ne peut pas les exposer par un backend mal configuré.

Sources

← Retour aux actualités