Base de données exposée dans le vibe coding : comment l’éviter avant la mise en ligne

Une base de données peut être exposée même lorsque l’application semble fonctionner parfaitement. L’interface utilisateur affiche les bonnes données, la connexion fonctionne, les API répondent, le déploiement passe et le fondateur peut faire une démonstration convaincante. Le risque naît ailleurs : une chaîne de connexion dans le dépôt, une base de données accessible depuis Internet, des règles trop permissives, une sauvegarde publique, un utilisateur avec des privilèges excessifs ou un point de terminaison généré par l’IA qui renvoie plus de données que prévu.

Dans le vibe coding, la base de données arrive très tôt. Des outils comme Lovable, Bolt.new, Replit Agent, Cursor, Copilot, Codex et Claude Code aident à connecter les tables, le stockage, l’authentification, les API, les tableaux de bord et le déploiement en un temps record. Cette rapidité est utile, mais elle pousse souvent vers des configurations qui font fonctionner le MVP immédiatement et reportent le durcissement (hardening). Pour les fondateurs, les chefs de produit et les développeurs juniors, la question avant la version bêta n’est pas seulement “la base de données répond-elle ?”, mais qui peut l’atteindre, avec quelles informations d’identification, depuis quels environnements, via quelles API, avec quelles règles, quelles sauvegardes, quels exports et quelles données réelles.

[Callforaction-WAPT]

Une base de données exposée ne signifie pas seulement injection SQL

Lorsqu’on parle de base de données exposée, beaucoup pensent immédiatement à l’injection SQL. C’est un risque important, mais dans les applications créées avec l’IA, l’exposition naît souvent avant : configuration, informations d’identification, autorisations, réseau, stockage, sauvegardes et API. Une base de données peut être protégée contre les injections et exposer tout de même des données parce qu’une politique est ouverte, qu’une clé est dans le client ou qu’un dump a fini dans un bucket.

Les erreurs les plus courantes sont pratiques : fichiers .env committés, chaînes de connexion dans les logs, RLS désactivée, règles de sécurité Firebase permissives, MongoDB accessible depuis des plages IP trop larges, Postgres avec un accès public inutile, base de données de staging avec des données réelles, clés de service utilisées par le frontend, sauvegardes téléchargeables, exports CSV non protégés et routes de débogage laissées en ligne. Le problème n’est pas la base de données choisie — PostgreSQL, Supabase, Firebase, MongoDB Atlas, RDS, Cloud SQL, PlanetScale, Neon, Pinecone, pgvector ou une base de données auto-hébergée peuvent être utilisés en toute sécurité — mais la publication d’une application avant d’avoir vérifié comment la donnée entre, est lue, est copiée et peut sortir.

Chaînes de connexion, fichiers .env et identifiants au mauvais endroit

La première exposition est souvent une chaîne de connexion. Pendant le développement avec l’IA, le développeur colle une URL de base de données dans le chat, l’agent génère un fichier .env, un exemple de déploiement finit dans le README, un log imprime la configuration ou une variable privée est placée dans le frontend pour résoudre une erreur. Une chaîne de connexion peut contenir l’hôte, la base de données, l’utilisateur, le mot de passe, les paramètres TLS et les privilèges : si elle finit dans Git, un prompt, un ticket, un log, un artefact ou un bundle, il ne suffit pas de la supprimer du fichier, elle doit être renouvelée (rotated). Même un identifiant de staging peut être critique si ce staging contient des données réelles ou a accès à des ressources partagées.

Avant la mise en ligne, il est nécessaire de rechercher les URL de base de données, mots de passe, clés de service, fichiers .env, fichiers .pem, dumps, sauvegardes et identifiants CLI dans les dépôts, l’historique Git, les branches, les tags, les logs CI/CD, les prompts, les tickets et les artefacts. L’étape suivante consiste à séparer les clés de développement, de staging et de production : une clé utilisée par l’agent ou en démonstration ne devrait jamais lire la base de données réelle.

Base de données accessible depuis Internet

De nombreuses bases de données cloud naissent avec un point de terminaison accessible. Parfois, c’est nécessaire ; souvent, c’est juste pratique. Si la base de données accepte des connexions depuis de larges plages IP, depuis tout Internet ou depuis des réseaux non contrôlés, les mots de passe et les secrets deviennent la seule barrière, ce qui est insuffisant pour un environnement de production. Pour un MVP, cela arrive lorsque l’équipe doit faire communiquer rapidement l’application, le tableau de bord, l’outil local et le déploiement.

Il est important de contrôler l’accès réseau, les listes d’autorisation IP (allowlist), les groupes de sécurité, les pare-feux, les VPC, le réseau privé et les règles de connexion. Dans un PostgreSQL auto-hébergé, des paramètres comme listen_addresses et pg_hba.conf décident d’où l’on peut entrer ; dans MongoDB Atlas, la liste d’accès IP est un contrôle clé ; dans les environnements cloud, les groupes de sécurité et les routes réseau doivent être cohérents avec l’architecture réelle. Une base de données de production ne devrait pas être accessible depuis chaque environnement temporaire, déploiement de prévisualisation ou ordinateur personnel sans nécessité : si un accès administratif est requis, il est préférable d’utiliser des canaux contrôlés comme un bastion, un VPN, un point de terminaison privé ou un accès temporaire.

Règles permissives dans Supabase, Firebase et BaaS

Les plateformes BaaS accélèrent considérablement le développement, mais la sécurité dépend des règles. Supabase nécessite une Row Level Security (RLS) et des politiques cohérentes pour isoler les utilisateurs et les locataires (tenants) ; Firebase utilise des règles de sécurité pour Firestore, Realtime Database et le stockage. Si l’IA génère une règle ouverte pour faire passer la démonstration, le fournisseur reste robuste mais la donnée peut sortir.

Dans Supabase, une table contenant des données privées ne devrait pas avoir de politiques génériques ou une RLS absente. La clé anonyme peut rester dans le client uniquement si la RLS et les politiques limitent réellement ce que le client peut lire et écrire, tandis que la clé de service (service role key) doit rester en dehors du frontend, des logs et du dépôt. Dans Firebase, des règles comme allow read, write: if true ou des contrôles basés uniquement sur request.auth != null peuvent être trop larges. Avant la mise en ligne, il est utile de tester la lecture et l’écriture avec différents utilisateurs, différentes données de locataires, un jeton absent, un jeton expiré et des requêtes directes, sans se fier au fait que l’interface utilisateur n’affiche que les bons enregistrements.

Utilisateurs de base de données trop privilégiés

Une application ne devrait pas se connecter à la base de données avec un utilisateur administratif si ce n’est pas nécessaire. Dans le vibe coding, cependant, l’IA peut suggérer l’identifiant qui “résout” l’erreur de permissions — superutilisateur, propriétaire de la base de données, rôle de service, compte avec accès à toutes les tables, clé avec privilèges globaux — rendant chaque bug plus coûteux. Si l’application subit une injection SQL, une SSRF, une RCE, une fuite de logs ou un point de terminaison abusif, l’attaquant hérite de privilèges trop larges. Même sans attaque externe, un agent IA avec un terminal ou des outils de base de données peut effectuer des opérations qui ne devraient pas être dans son périmètre.

Le contrôle correct est le principe du moindre privilège. Cela signifie utiliser des utilisateurs séparés pour l’application, les migrations, les tâches de maintenance, la lecture analytique et l’administration, en limitant les permissions aux tables, schémas et opérations nécessaires, et en évitant les utilisateurs d’exécution avec des droits DROP, ALTER, des privilèges globaux ou un accès à des données hors périmètre.

Sauvegardes, dumps et exports exposés

Souvent, la base de données opérationnelle est mieux protégée que ses copies. Les dumps SQL, exports CSV, instantanés (snapshots), sauvegardes automatiques, fichiers temporaires, rapports, artefacts de pipeline et dossiers de support peuvent contenir l’intégralité du patrimoine de données. Dans un MVP, ces fichiers sont créés pour le débogage, la migration, la démonstration ou les tests, puis oubliés dans des buckets cloud, le stockage BaaS, les dépôts, les environnements de staging, les ordinateurs portables, les systèmes de tickets, les e-mails, le CI/CD, les images de conteneurs ou les dossiers temporaires.

Les sauvegardes et les dumps doivent avoir des accès limités, un chiffrement approprié, une rétention définie, une journalisation des accès et une séparation des actifs publics. Un dump réel en staging peut être plus exposé que la production, et un export CSV généré par une route admin peut être téléchargeable sans contrôles adéquats. Si une copie contient des données réelles, elle doit être traitée comme la production.

API générées qui exposent la base de données

Même lorsque la base de données n’est pas directement publique, les API peuvent l’exposer. Un agent peut générer des points de terminaison CRUD, des routes admin, des fonctions de recherche, des exports, des débogages, des filtres, des rapports ou des tableaux de bord qui lisent des données sans autorisation suffisante, rendant de fait le point de terminaison la base de données exposée.

Exemples fréquents : /api/users renvoie tous les utilisateurs, /api/orders?user_id=... accepte un ID du client sans vérification, /api/export produit un CSV complet, /api/debug/db reste actif en production, une route admin ne contrôle que la connexion, une recherche globale ignore les locataires et les rôles, une fonction serverless utilise la clé de service et ne filtre pas les résultats. Avant la mise en ligne, il est nécessaire de faire l’inventaire des routes qui lisent dans la base de données et de tester des appels directs, des paramètres manipulés, des jetons manquants, un rôle faible, un locataire différent et des méthodes HTTP non prévues. Si un point de terminaison renvoie des données que l’interface utilisateur ne montrerait pas, la base de données est exposée via l’application.

Stockage, buckets et métadonnées liés à la base de données

De nombreuses applications associent des enregistrements de base de données à des fichiers : documents, images, pièces jointes, factures, avatars, contrats, rapports, exportations, jeux de données. Si la base de données ne contient que le chemin mais que le bucket est public, la protection de l’enregistrement ne suffit pas ; si l’URL est prévisible, un utilisateur peut télécharger les fichiers d’autrui même sans requête à la base de données.

Il est nécessaire de vérifier les buckets, les chemins, les URL signées, la durée des liens, les politiques par utilisateur ou locataire, les aperçus, les vignettes, le texte extrait et les métadonnées. Un fichier peut être privé mais avoir un aperçu public, un nom de fichier peut révéler des informations client et un export peut être enregistré dans le stockage et rester accessible après l’expiration prévue. Le test pratique est simple : charger des fichiers avec deux utilisateurs différents, puis essayer des téléchargements et suppressions croisés en changeant l’ID, le chemin ou le nom du fichier. Si l’application utilise Supabase Storage, Firebase Storage, S3 ou similaire, le contrôle doit inclure à la fois les politiques de stockage et la logique applicative.

Staging, prévisualisation et données réelles

L’une des erreurs les plus courantes est d’utiliser des données réelles en dehors de la production. L’équipe copie un dump pour le débogage, connecte un déploiement de prévisualisation à la base de données réelle, utilise les mêmes clés en staging, importe des clients pour une démonstration ou teste un agent sur des données réelles. Ces environnements ont généralement moins de contrôles, plus de personnes ayant accès et des logs plus verbeux.

La séparation dev/staging/prod doit concerner la base de données, le stockage, les clés, les utilisateurs, les rappels (callbacks), les sauvegardes et les outils d’observabilité. Si des données réalistes sont nécessaires, il est préférable d’utiliser des jeux de données synthétiques, du masquage ou des sous-ensembles minimisés, en évitant que les URL de prévisualisation, les branches temporaires ou les environnements générés par l’IA ne pointent vers la base de données réelle. Lorsqu’une base de données de staging contient des données réelles, elle doit être traitée comme la production : accès limités, sauvegardes protégées, journalisation, rétention, correctifs et contrôle des identifiants.

Base de données vectorielle, RAG et fuite de documents

Les applications IA qui utilisent le RAG ajoutent une autre forme de base de données : magasin vectoriel, magasin d’embeddings, index de documents. ChromaDB, Pinecone, pgvector et d’autres systèmes peuvent contenir des fragments de documents, tickets, e-mails, contrats, manuels, bases de connaissances et données client. Si la récupération (retrieval) n’applique pas d’autorisation, un utilisateur peut recevoir un contexte appartenant à d’autres.

La sécurité de la base de données vectorielle ne se limite pas au moteur de base de données, mais nécessite de contrôler ce qui est indexé, avec quelles métadonnées, dans quel espace de noms (namespace) ou locataire, qui peut le récupérer, quels filtres sont appliqués avant la récupération et quels documents finissent dans les logs ou dans le prompt du modèle. Pour les applications multi-locataires, il est nécessaire de séparer les espaces de noms ou d’appliquer des filtres d’autorisation robustes, de journaliser quels documents sont récupérés et de prévoir la suppression et la réindexation lorsqu’un utilisateur supprime des données ou modifie des permissions. Si le modèle reçoit des documents non autorisés, la réponse peut déjà avoir exposé la donnée.

Agents IA avec accès à la base de données

Lorsqu’un agent peut utiliser un terminal, MCP, des outils SQL, des tableaux de bord cloud ou des identifiants d’exécution, la base de données devient une partie de son périmètre opérationnel. Le risque n’est pas seulement que l’agent génère du mauvais code : il peut exécuter des requêtes, modifier des données, lancer des migrations, lire des tables ou imprimer des résultats dans le chat et les logs.

Ne donnez pas à un agent des identifiants de production si ce n’est pas strictement nécessaire. Il est préférable d’utiliser des bases de données sandbox, des données synthétiques, des utilisateurs en lecture seule, des permissions temporaires et une approbation pour les commandes destructrices. Si l’agent doit générer des migrations, il convient de les examiner avant de les appliquer ; s’il doit interroger des données, il est nécessaire de limiter les tables et les lignes disponibles. Pour les agents connectés via MCP ou des outils externes, il faut cartographier quelles actions sont possibles — lire, écrire, supprimer, exporter, créer des utilisateurs, modifier le schéma, accéder au gestionnaire de secrets — et appliquer le principe du moindre privilège : l’agent ne doit avoir que ce qui est nécessaire pour la tâche, pas tout ce qui est pratique.

Que vérifier avant la version bêta

Avant d’ouvrir une version bêta ou d’importer des données réelles, il est utile de préparer un inventaire des données : quelles bases de données existent, quels environnements les utilisent, quels utilisateurs et clés y accèdent, quelles API lisent ou écrivent, quelles sauvegardes sont actives, quels buckets contiennent des fichiers liés aux enregistrements, quels agents ou pipelines ont des identifiants.

Ensuite, il est nécessaire d’effectuer des tests pratiques : recherche de secrets dans les dépôts et l’historique, contrôle réseau, vérification des politiques, accès avec un utilisateur aux privilèges minimisés, tests d’API sur les exports et les routes de débogage, téléchargement de fichiers avec différents utilisateurs, recherche de dumps et sauvegardes dans les artefacts, contrôle du staging et de la prévisualisation. Ces étapes permettent de trouver des problèmes qu’une démonstration ne montre pas.

Signaux indiquant que la base de données est déjà trop exposée

Certains signaux méritent une attention immédiate même si aucune violation n’a encore été trouvée : un fichier .env committé, une chaîne de connexion dans un log, une base de données qui accepte des connexions depuis des IP non reconnues, une sauvegarde dans un bucket partagé, un tableau de bord admin accessible en dehors du réseau prévu, un déploiement de prévisualisation avec des données réelles, un export CSV avec plus de colonnes que nécessaire.

D’autres signaux émergent du comportement de l’application : une requête de liste renvoie les enregistrements de tous les utilisateurs et l’interface utilisateur filtre ensuite côté client, un point de terminaison accepte limit=100000 et produit des exports complets, une fonction de recherche renvoie des résultats inter-locataires, un utilisateur de base de données utilisé par l’application peut lire des tables qu’aucune fonctionnalité n’utilise, un agent IA peut exécuter des requêtes sur la production pour aider au débogage. Ces signaux ne sont pas tous des incidents, mais indiquent que le périmètre des données n’est pas gouverné. Avant de connecter des utilisateurs réels, il vaut la peine de s’arrêter et de reconstruire le parcours de la donnée : entrée, requête, API, stockage, logs, sauvegardes, exports et suppression.

Que corriger avant et que planifier

La priorité doit être donnée à tout ce qui permet un accès direct ou une copie massive des données. Les chaînes de connexion de production exposées, les bases de données accessibles depuis des réseaux non prévus, les sauvegardes publiques, les clés de service dans le frontend, les utilisateurs de base de données administratifs utilisés par l’application, les exports sans autorisation et les règles ouvertes sur des données privées doivent être corrigés avant la mise en ligne.

La remédiation doit fermer le risque, pas seulement le cacher. Si une chaîne de connexion a été divulguée, il faut renouveler l’identifiant et vérifier les logs d’accès. Si une base de données était accessible depuis Internet, il est nécessaire de restreindre le réseau et de vérifier qui s’est connecté. Si une sauvegarde était publique, il faut supprimer l’accès, renouveler les clés incluses et évaluer ce qu’elle contenait. Si une politique était ouverte, il est nécessaire d’ajouter des tests négatifs avec différents utilisateurs et locataires.

D’autres améliorations peuvent être planifiées avec des responsables et des échéances : renforcer le nommage des variables, automatiser la recherche de secrets, documenter les utilisateurs de base de données, réduire la rétention, améliorer les alertes, mieux séparer le staging et la production. La protection de la base de données et de ses copies doit cependant être traitée comme une exigence de publication, et non comme une finition ultérieure.

Comment ISGroup peut vérifier les bases de données, le stockage et les API

ISGroup peut vérifier si une application créée avec l’IA expose la base de données via des configurations, des identifiants, des surfaces en ligne, des API, des sauvegardes, du stockage ou le cloud. Le contrôle commence par la manière réelle dont la donnée est atteinte : réseau, application, BaaS, stockage, pipelines et agents.

Si le projet a…	Risque principal	Contrôle conseillé
Base de données, hôte, services, panneaux ou points de terminaison accessibles	Expositions techniques et configurations connues	Vulnerability Assessment
Web app, API, exports, uploads ou routes qui lisent des données	Abus applicatif et accès non autorisé	Web Application Penetration Testing
Base de données cloud, buckets, IAM, groupes de sécurité, VPC, BaaS ou sauvegardes	Mauvaise configuration cloud ou privilèges excessifs	Cloud Security Assessment
Chaînes de connexion, requêtes, politiques, utilisateurs DB ou logique côté serveur dans le code	Erreurs d’implémentation et secrets dans le code	Code Review
Codage IA utilisé de manière continue sur les bases de données, migrations et déploiements	Contrôles non répétables sur les versions	Software Assurance Lifecycle

Le choix du contrôle dépend de l’endroit d’où la donnée peut sortir : base de données accessible, API abusive, sauvegarde exposée, bucket public, clé dans le code ou agent avec des permissions excessives. Avant la version bêta, il convient de délimiter ces chemins et de fermer les expositions les plus critiques.

Vous avez créé une application avec l’IA et vous êtes sur le point de la connecter à des données réelles ? ISGroup peut vérifier la base de données, le stockage, les API, les identifiants, les sauvegardes, les règles et les configurations avant que le MVP ne devienne un risque opérationnel.

Évidences à préparer

Pour démarrer une vérification, il est utile de préparer une liste des bases de données, fournisseurs, environnements, chaînes de connexion gérées, utilisateurs DB, rôles, politiques, sauvegardes, stockage, API, dépôts, pipelines, agents utilisés et parties générées avec l’IA. Si vous utilisez un BaaS, il est nécessaire d’inclure le projet Supabase ou Firebase avec les règles, buckets et clés ; si vous utilisez une base de données cloud, incluez le réseau, les groupes de sécurité, la liste d’autorisation IP, le VPC et les comptes de service.

Des données de test sont également nécessaires : deux utilisateurs, deux locataires si présents, des enregistrements similaires, des fichiers chargés, des exports, des sauvegardes et des comptes avec des privilèges différents. Sans ces éléments, il est difficile de démontrer si l’application isole réellement les données et les copies. Si vous avez déjà reçu des alertes sur des secrets, des règles permissives, des bases de données publiques, des buckets ouverts ou des dumps partagés, il est opportun de les inclure : souvent, une alerte unique révèle un processus qui doit être corrigé avant la mise en ligne.

Décision avant la mise en ligne

Bloquez la mise en ligne si vous trouvez des chaînes de connexion de production exposées, une base de données accessible depuis des réseaux non prévus, une RLS ou des règles de sécurité ouvertes sur des données privées, des utilisateurs de base de données trop privilégiés, des sauvegardes ou dumps téléchargeables, des buckets publics avec des documents privés, des API qui exportent des données sans autorisation ou des agents avec des identifiants de production non contrôlés.

Vous pouvez planifier après la sortie uniquement les améliorations avec un risque résiduel clair : documentation, alertes supplémentaires, réduction progressive des privilèges non critiques, nommage des clés, automatisation des contrôles. La protection de la donnée opérationnelle doit être verrouillée avant d’utiliser des clients, des paiements, des documents ou des informations d’entreprise.

Checklist base de données exposée

• Recherchez les chaînes de connexion et identifiants dans le code, les fichiers .env, l’historique, les prompts, les logs et les artefacts.
• Vérifiez la liste d’autorisation IP, les pare-feux, les groupes de sécurité, les VPC et l’accès administratif.
• Contrôlez la RLS, les règles de sécurité, les ACL et les politiques sur les tables et le stockage.
• Utilisez des utilisateurs DB aux privilèges minimaux, séparés par environnement.
• Protégez les sauvegardes, dumps, instantanés, exports et rapports.
• Testez les API, routes de débogage, exports et tableaux de bord qui lisent dans la base de données.
• Vérifiez les buckets, URL signées, aperçus et métadonnées liés aux enregistrements.
• Évitez les données réelles en staging, prévisualisation et environnements agentiques.
• Isolez la base de données vectorielle et la récupération par utilisateur ou locataire.
• Limitez les agents IA et les outils MCP avec accès à la base de données.

Questions fréquentes

• Une base de données exposée signifie-t-elle forcément un accès public direct ?
• Non. Cela peut aussi signifier une chaîne de connexion exposée, une sauvegarde téléchargeable, une API trop permissive, un bucket public, une RLS désactivée, un staging avec des données réelles ou une base de données vectorielle sans isolation.
• Si la base de données n’est pas publique, suis-je en sécurité ?
• Pas nécessairement. La donnée peut sortir via des API, des exports, des logs, des sauvegardes, du stockage, des identifiants dans le code ou des agents ayant accès à la base de données.
• Quelle est la différence entre un Vulnerability Assessment et un Web Application Penetration Testing dans ce cas ?
• Le Vulnerability Assessment aide à cartographier les services et configurations exposés. Le WAPT teste si l’application et les API permettent de lire ou modifier des données de manière abusive.
• Supabase ou Firebase évitent-ils le problème ?
• Ils offrent des contrôles utiles, mais la RLS, les règles de sécurité, les buckets, les clés, les utilisateurs et la séparation des environnements doivent être configurés et testés sur le projet réel.
• Les sauvegardes doivent-elles être protégées comme la base de données ?
• Oui. Elles contiennent souvent plus de données que la base de données opérationnelle et sont moins surveillées. Les dumps, instantanés et exports avec des données réelles doivent avoir des accès, une rétention et un stockage contrôlés.
• Qu’est-ce qui change avec une base de données vectorielle ?
• La donnée peut être récupérée comme contexte du modèle. Si les filtres, les espaces de noms ou l’isolation des locataires ne fonctionnent pas, un utilisateur peut recevoir des informations indexées à partir des documents d’autrui.

[Callforaction-WAPT-Footer]

Sources et références utiles

• Supabase Row Level Security : https://supabase.com/docs/guides/database/postgres/row-level-security
• Supabase Hardening Data API : https://supabase.com/docs/guides/database/hardening-data-api
• Supabase Securing your API : https://supabase.com/docs/guides/api/securing-your-api
• Firebase Security Rules : https://firebase.google.com/docs/rules/
• Firebase Realtime Database Security Rules : https://firebase.google.com/docs/database/security
• MongoDB Atlas IP Access List : https://www.mongodb.com/docs/atlas/security/ip-access-list/
• PostgreSQL Connections and Authentication : https://www.postgresql.org/docs/current/runtime-config-connection.html
• Pinecone multitenancy : https://docs.pinecone.io/guides/get-started/implement-multitenancy
• OWASP API Security : https://owasp.org/www-project-api-security/
• OWASP Top 10 for LLM Applications : https://genai.owasp.org/llm-top-10/