IA
Supabase : 16 000 bases exposent des données
Une mauvaise configuration du contrôle d'accès dans 16 326 bases de données Supabase expose des données personnelles et des identifiants. UpGuard pointe l'usage d'agents d'intelligence artificielle qui créent ces tables via l'API sans activer les protections nécessaires.
Par Mila · rédaction IA
Le 25 septembre 2026, l'entreprise de cybersécurité UpGuard a publié un rapport établissant que 16 326 bases de données hébergées sur Supabase étaient accessibles en lecture publique sans authentification.
Les applications créées via des invites de code omettent souvent de verrouiller l'accès aux tables PostgreSQL. Les administrateurs de projets web doivent immédiatement auditer les permissions de leurs bases pour bloquer les requêtes publiques non autorisées.
L'audit d'UpGuard recense 16 326 bases ouvertes
L'entreprise de cybersécurité UpGuard détaille dans son rapport d'audit une exposition massive touchant l'infrastructure de Supabase. Les analystes ont scruté un échantillon de 300 000 domaines web identifiés grâce aux outils BuiltWith et au Chrome UX Report de Google. Sur cet ensemble, 16 326 bases laissaient leurs tables ouvertes aux requêtes directes sans exiger le moindre identifiant de connexion. Plus de la moitié d'entre elles contenaient des informations personnelles identifiables. Ce constat oblige les gestionnaires de plateformes en ligne à vérifier si leur nom de domaine figure parmi les projets inspectés lors de ce recensement mondial.
Le filtrage par ligne désactivé livre les tables
Le mécanisme Row Level Security de PostgreSQL permet de restreindre l'accès aux enregistrements selon le profil de l'utilisateur qui envoie la requête. Supabase active cette protection par défaut dans sa console graphique, mais ne l'impose pas lors de la création de tables par l'interface de programmation applicative. Les données restent alors interrogeables par n'importe quel internaute qui extrait la clé publique de l'application depuis le code JavaScript affiché dans le navigateur. D'après l'article de BleepingComputer, la mauvaise écriture des politiques d'accès ou la confusion entre clé publique et clé secrète transforment cette configuration en point d'entrée universel. Les équipes techniques doivent inscrire l'activation systématique de cette protection dans leurs scripts de déploiement.
Les agents de code IA omettent les règles
La création de bases via des outils d'automatisation logicielle explique l'ampleur du problème chez de nombreuses jeunes entreprises. Plus de 60 % des nouvelles bases Supabase sont désormais générées avec l'aide de modèles d'intelligence artificielle comme Claude Code ou OpenAI Codex. En mars 2025, la vulnérabilité CVE-2025-48757 signalée par Matt Turner avait déjà révélé des faiblesses similaires avec l'outil Lovable, touchant 28 % des 107 jeunes pousses de Y Combinator testées par Modern Pentest. Comme l'observe Clubic, les développeurs qui utilisent ces assistants automatisés valident le schéma sans en comprendre les paramètres de sécurité sous-jacents. Ce défaut de relecture transfère un risque juridique majeur aux fondateurs qui déploient sans audit préalable.
Des passeports et messages privés restent lisibles
Les données recueillies par les chercheurs démontrent que des pans entiers d'activité sont touchés par ces négligences de paramétrage. Une plateforme indienne de créateurs a laissé fuiter les données de 65 467 utilisateurs, incluant des numéros de passeport, des permis de conduire et plus de 100 000 messages privés. Un service d'envoi de codes temporaires aux Philippines exposait 100 000 SMS et les accès de 2 000 usagers, tandis qu'un service d'immigration canadien enregistrait 884 mots de passe en clair. Un consulat africain a également vu les dossiers de 25 000 ressortissants et leurs adresses de relogement d'urgence exposés. Ces fuites concrètes transforment une erreur technique en risque direct d'usurpation d'identité et de sanctions réglementaires pour les exploitants négligents.
Les équipes doivent auditer leurs tables sans délai
La remédiation impose un contrôle direct sur l'ensemble des projets Supabase déjà en production. Les administrateurs doivent consulter les conseillers de sécurité intégrés à la plateforme et appliquer le guide de sécurisation officiel pour verrouiller l'API. Chaque table doit impérativement activer la protection par ligne et définir des règles d'interrogation strictes pour la clé anonyme client. Le 25 septembre 2026, date de parution de l'étude, l'API de Supabase n'activait toujours pas cette sécurité par défaut. Les développeurs doivent donc revoir manuellement chacun de leurs fichiers de migration pour bloquer définitivement les requêtes non filtrées.
- 16 326 bases de données Supabase exposées et lisibles sans identifiant Rapport UpGuard 25 septembre 2026
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 la configuration.
Le recours aux agents de génération de code permet de bâtir un produit fonctionnel en quelques minutes, mais délègue la configuration de la sécurité à des scripts qui privilégient le fonctionnement immédiat sur la fermeture des accès aux données.
Pour un professionnel indépendant ou une petite structure qui gère son site sans équipe technique, la plateforme n'exige aucun coût financier supplémentaire mais impose une vérification immédiate : activer la Row Level Security sur chaque table via la console Supabase prend environ deux heures et évite une violation des données clients.
Pourquoi la clé publique anon de Supabase ne protège-t-elle pas les données ?
La clé anon est intégrée dans le code JavaScript du navigateur et reste lisible par tous. Elle ne filtre rien par elle-même : seule l'activation de la Row Level Security sur PostgreSQL bloque les requêtes non autorisées.
Comment savoir si une base de données Supabase est vulnérable ?
Il suffit d'ouvrir la console du projet, de vérifier l'onglet sécurité et de s'assurer que la Row Level Security est cochée et dotée de règles d'accès explicites pour chaque table existante.
- Une analyse d'UpGuard sur 300 000 domaines révèle 16 326 bases Supabase accessibles sans authentification.
- Le problème vient de tables créées par API ou par agents IA sans activation de la sécurité au niveau des lignes.
- La plateforme recommande d'activer la Row Level Security et d'auditer les projets via ses conseillers intégrés.