Actualités / Cybersécurité
16 000 bases Supabase exposées : des données sensibles accessibles via des configurations défaillantes Publié le 29 septembre 2026 par Christ-loisele (3 min de lecture)
Des chercheurs d’UpGuard révèlent que 16 000 bases de données Supabase, utilisées par des entreprises et administrations, laissent des données critiques accessibles en raison de paramètres de sécurité mal configurés. Parmi les victimes : un consulat africain, des services d’immigration canadiens et des plateformes indiennes.
Une faille généralisée liée à l’usage croissant de l’IA en développement
Les chercheurs d’UpGuard ont identifié plus de 16 000 bases de données Supabase exposées en raison de configurations de sécurité défaillantes, selon BleepingComputer . La plateforme Supabase, construite autour de PostgreSQL, est largement adoptée pour son accessibilité, notamment grâce à l’automatisation par l’intelligence artificielle. Selon UpGuard, plus de 60 % des nouvelles bases créées sur Supabase le sont via des outils assistés par IA, ce qui augmente les risques d’erreurs de configuration.
L’exposition des données résulte principalement de l’absence ou de l’inefficacité des politiques de sécurité au niveau des lignes (Row Level Security, RLS). Les tables contenant des informations personnelles, des mots de passe en clair, des jetons d’authentification ou des détails de paiement étaient accessibles via l’API REST de Supabase, comme l’explique dev.to . Les requêtes utilisant uniquement une clé publique sont évaluées sous le rôle anon de PostgreSQL, contournant ainsi les vérifications d’authentification utilisateur.
Les configurations de sécurité restent invariantes au type d’activité parce que les utilisateurs, qui connaissent leur secteur, ignorent souvent les paramètres de leur base de données.
Illustration : Lawing Tech Des secteurs variés touchés, dont des administrations et services sensibles
Les données exposées concernent des secteurs critiques. Un service de valet américain a laissé fuiter plus de 100 000 enregistrements clients, incluant plaques d’immatriculation et historiques de visites. Un service d’immigration canadien a exposé près de 5 000 dossiers, dont 884 mots de passe en clair, selon BleepingComputer . En Asie, une plateforme indienne dédiée aux créateurs de contenu adulte a vu ses bases exposer identités, comptes de paiement et plus de 100 000 messages privés, tandis qu’un service philippin de messages OTP a perdu des données sur 2 000 utilisateurs et 100 000 SMS.
En Afrique, un consulat gouvernemental a exposé les données de 25 000 personnes, incluant adresses et localisations d’hébergement d’urgence. Ces cas illustrent la vulnérabilité des infrastructures publiques et privées lorsque les configurations de sécurité ne sont pas adaptées aux besoins réels.
Ce que cela change ici : des risques accrus pour les entreprises et administrations africaines
Pour les entreprises et administrations du Bénin et d’Afrique de l’Ouest, cette faille souligne l’urgence d’adopter des pratiques de sécurité rigoureuses, surtout lorsque des outils de développement automatisés sont utilisés. L’absence de politiques de sécurité au niveau des lignes (RLS) ou leur mauvaise configuration pourrait exposer des données sensibles, comme les informations personnelles des citoyens ou les transactions financières, à des cyberattaques ou à des fuites accidentelles.
Les administrations publiques, en particulier, devraient auditer leurs bases de données pour vérifier l’activation des mécanismes de sécurité et former leurs équipes aux bonnes pratiques. Les entreprises utilisant Supabase ou des solutions similaires devraient également limiter l’accès aux clés API et privilégier les rôles d’accès minimalistes, comme recommandé par Supabase lui-même. Une vigilance accrue sur les configurations pourrait éviter des incidents comparables à ceux documentés.
Comment détecter et corriger les vulnérabilités ?
UpGuard et les experts de Supabase soulignent que les vulnérabilités découlent souvent d’une méconnaissance des configurations de sécurité. Les administrateurs devraient vérifier que les politiques RLS sont activées sur les tables exposées via l’API et restreindre les permissions selon le principe du moindre privilège. Dev.to recommande également de croiser les logs des requêtes API avec les audits côté base de données pour détecter toute activité suspecte.
Supabase préconise de définir des politiques RLS basées sur l’appartenance et les attributs d’authentification, et d’éviter l’utilisation de clés service_role en production, sauf si strictement nécessaire. Pour les organisations utilisant des outils de développement assisté par IA, une revue humaine des configurations reste indispensable.
Sources 
