Une étude qui fait mal Une étude menée par un spécialiste de la sécurité a identifié 16 326 bases de données exposant des tables lisibles par n'importe qui sur internet. Toutes hébergées sur une même plateforme de base de données, très utilisée dans les applications vibe codées. Plus de la moitié contiennent des indicateurs de données personnelles. Une partie stocke des mots de passe ou des jetons d'authentification. Le lien avec le vibe coding Cette plateforme s'est imposée comme brique centrale des applications générées par IA. Au point d'être la solution de base de données la plus recommandée par certains agents de codage. Quand l'agent propose une stack, c'est elle qui sort. La cause technique Elle est précise, et presque bête. Après une vulnérabilité signalée en mars 2025, la plateforme a activé par défaut la sécurité au niveau des lignes, le RLS, pour les tables créées via son interface graphique. Mais pas pour les tables créées par API. Or c'est exactement comme ça que procèdent les agents de codage. L'agent crée la table, l'application fonctionne, les tests passent. Et la base est ouverte. Des cas très concrets Un service de codes SMS aux Philippines : 2 000 utilisateurs et 100 000 messages exposés. Un service de voiturier aux États-Unis : plus de 100 000 clients, données complètes. Un service lié à l'immigration au Canada : 5 000 enregistrements, dont 884 mots de passe en clair. Fonctionnel ne veut pas dire sûr L'étude résume le mécanisme. La facilité de mauvaise configuration se multiplie avec l'absence de compréhension des bonnes configurations, que le développeur soit humain ou agent. C'est le point essentiel. Une application peut passer tous les tests fonctionnels, être validée en recette métier, et rester totalement exposée. Tester qu'une application marche ne dit rien de ce qu'elle laisse ouvert. Ce qu'il faut ajouter au pipeline Le scénario typique est connu. Un prototype livré en quelques jours avec un agent de codage devient l'application de production. Personne ne revérifie la configuration de la base. Deux actions immédiates : contrôler l'état du RLS sur toutes les tables des bases en production générées avec un agent, et ajouter au pipeline un test automatique qui tente une lecture anonyme sur chaque table avant chaque déploiement. Un test de quelques secondes. Qui suffit à repérer ce type d'exposition avant la mise en ligne.
