Apps en vibe coding : sûres ? 8 failles à vérifier

Les apps créées en vibe coding sont-elles sûres ?

Pas par défaut : les grandes études citées ici ont toutes trouvé de graves failles de sécurité dans une large part des apps examinées ^[3][4][5]. Les apps fonctionnent en général. Le problème, c'est ce qu'elles permettent à des inconnus.

Un audit de 2026 a rassemblé 9041 apps open source créées avec Claude Code et Lovable et en a examiné 200 déployées publiquement. Il a relevé 1186 vulnérabilités, et 182 des 200 apps (91,0 %) en avaient au moins une ^[4]. Parmi ces failles, 65,77 % étaient classées critiques ou élevées, dont 18,47 % critiques ^[4].

Les auteurs ont aussi vérifié si de meilleurs prompts et réglages d'agents réglaient le problème. Ils l'ont réduit sans l'éliminer, et une même tâche lancée trois fois pouvait donner un résultat sûr une fois et un résultat vulnérable la suivante ^[4]. Autrement dit, un résultat propre sur une version en dit peu sur la suivante.

Pour les bases de la méthode, voir le guide Pouyam Vibe Coding Explained: What It Is, How It Works and the Real Risks. Pour un premier projet, Vibe Coding for Beginners: How to Start Safely in 2026 propose un plan de départ. Cette page va un cran plus loin : les failles précises et la façon de tester chacune.

Que trouvent les études de sécurité dans les apps en vibe coding ?

Quatre sources indépendantes pointent le même point faible : des données que la mauvaise personne peut lire ou modifier ^[1][3][4][5].

• Audit de 200 apps déployées (2026) : le contrôle d'accès défaillant était la première catégorie, avec 339 des 1186 failles (28,58 %), et touchait 64,00 % des apps. L'injection touchait 54,00 % des apps et les défauts d'authentification 51,50 % ^[4].
• Étude ACM CCS 2026 : sur 8641 dépôts Lovable avec historique complet, 11,2 % des règles de lecture étaient ouvertes aux visiteurs non connectés et 61,2 % des dépôts avaient au moins une telle règle. Un test de rejeu a confirmé l'exposition dans 353 des 400 dépôts échantillonnés ^[5].
• Escape (octobre 2025) : une analyse passive de plus de 5600 apps publiques créées sur des plateformes comme Lovable, Base44 et Create.xyz a trouvé plus de 2000 vulnérabilités, plus de 400 secrets exposés et 175 cas de données personnelles, dont des dossiers médicaux, des IBAN (identifiants de compte bancaire), des téléphones et des e-mails ^[3].
• CVE-2025-48757 (2025) : une analyse achevée le 21 mars 2025 a trouvé 303 points d'accès de base de données dans 170 des 1645 projets Lovable, soit environ 10,3 %, avec des règles de ligne insuffisantes ^[1].

Escape souligne que son analyse a évité toute action destructrice, ses chiffres sont donc un minimum ; un test plus poussé en trouverait davantage ^[3]. La même prudence vaut pour tous ces chiffres : ces études comptent ce qui était visible de l'extérieur.

Pourquoi les outils d'IA créent-ils des apps vulnérables ?

Parce que les outils visent une app qui fonctionne, et que les règles de sécurité dépendent de détails métier que le prompt précise rarement ^[4][11].

Un code qui tourne est facile à vérifier : la page s'affiche, le bouton répond. Savoir qui peut voir chaque enregistrement est une décision métier, et si personne ne l'écrit, l'outil doit deviner. L'audit de 2026 rattache les failles à huit schémas d'échec récurrents, regroupés en trois limites des agents d'IA : la mémoire, les objectifs et les connaissances ^[4].

Les tests à grande échelle des modèles d'IA montrent le même écart. Le GenAI Code Security Report 2026 de Veracode a constaté que, dans ses tests, environ 44 % des tâches de génération de code introduisaient une vulnérabilité de sécurité ^[11]. Un benchmark cité par AWS a montré que le meilleur des 12 réglages d'agents résolvait correctement 57 % des tâches, mais seulement 11,8 % de façon à la fois correcte et sûre ^[10].

Beaucoup d'apps en vibe coding reportent en outre la sécurité sur la base de données. Le navigateur dialogue directement avec une base hébergée, si bien que ses règles sont la seule barrière entre un visiteur et chaque ligne ^[1][6]. Si les règles manquent ou sont trop larges, quiconque connaît l'adresse peut tout demander.

Quelles 8 failles de sécurité vérifier en premier ?

Commencez par les failles que les études trouvent le plus souvent, classées selon les dégâts possibles ^[1][3][4][5].

1. Règles de base de données ouvertes : des tables sans row level security, ou avec des règles qui laissent tout visiteur lire toutes les lignes. C'était l'origine de la CVE-2025-48757 et des résultats de l'étude ACM ^[1][5].
2. Contrôle d'accès défaillant : un utilisateur connecté ouvre l'enregistrement d'un autre en changeant un identifiant dans l'adresse ou la requête. C'était la première catégorie de l'audit de 2026 ^[4].
3. Clés secrètes dans le navigateur : une clé secret ou service_role de Supabase, une clé de paiement ou une clé d'un fournisseur d'IA placée dans le code front-end. Escape a trouvé plus de 400 secrets exposés ^[3][6].
4. Contrôles de connexion absents ou faibles : des pages privées ou des routes d'API qui répondent sans session. Les défauts d'authentification touchaient 51,50 % des apps auditées ^[4].
5. Injection : des saisies d'utilisateurs qui atteignent les requêtes ou le HTML sans contrôle, constatée dans 54,00 % des apps auditées ^[4].
6. Tables modifiables : des règles qui permettent aux visiteurs d'insérer ou de modifier des données, pas seulement de les lire. Dans le cas de la CVE, une requête sans jeton de connexion a inséré un enregistrement marqué "payé" en sautant l'étape de paiement ^[1].
7. Réponses trop bavardes : des API qui renvoient des fiches utilisateur entières, des e-mails ou des jetons alors que la page n'a besoin que d'un nom. Escape a compté 175 cas de données personnelles exposées ^[3].
8. Accès risqué des agents : un agent de code qui détient des identifiants de production peut faire de vrais dégâts ; en juillet 2025, un agent a supprimé une base de données en production pendant un gel du code ^[10].

Les failles 1 à 4 couvrent l'essentiel de ce qu'exploitent les attaquants extérieurs : testez-les avant tout.

Comment tester mon app en vibe coding contre ces failles ?

Utilisez l'app comme le ferait un attaquant : en inconnu, en second utilisateur et en lisant ce que reçoit le navigateur ^[1][4][5]. Aucune de ces étapes ne demande d'outil spécial.

1. Créez deux comptes de test. Créez un enregistrement avec le compte A, copiez son adresse ou son identifiant, connectez-vous avec le compte B et essayez de l'ouvrir, de le modifier et de le supprimer. Si cela marche, le contrôle d'accès est défaillant ^[4].
2. Recommencez déconnecté. Ouvrez les mêmes adresses dans une fenêtre privée sans session. Dans le cas de la CVE, retirer l'en-tête de connexion suffisait à contourner tous les contrôles ^[1].
3. Observez l'onglet Réseau. Dans les outils de développement du navigateur, regardez chaque requête de la page et sa réponse. Les réponses ne doivent contenir que ce dont l'écran a besoin, jamais les e-mails ou jetons d'autres utilisateurs ^[3].
4. Cherchez des clés dans le code de la page. Recherchez les chaînes commençant par sb_secret_, la mention service_role ou des clés de fournisseurs, de paiement ou d'IA par exemple. Une clé publishable est normale ; une clé secret est une urgence ^[6].
5. Vérifiez les règles de chaque table. Dans le tableau de bord de la base, confirmez que row level security est activée sur chaque table et lisez chaque règle en termes simples : qui peut lire, qui peut écrire ^[7].
6. Essayez des saisies anormales. Collez des textes très longs, des guillemets et des balises HTML dans chaque formulaire et voyez si l'app plante ou les affiche comme du code ^[4].

Ne testez que des apps qui vous appartiennent ou que vous avez le droit de tester. Ne sondez pas les apps d'autrui sans autorisation écrite.

Comment corriger des règles Supabase ouvertes et des clés exposées ?

Activez row level security sur chaque table, écrivez des règles strictes, gardez les clés secrètes côté serveur et remplacez toute clé exposée ^[6][7][8].

• Activez row level security partout. Le guide de Supabase demande de l'activer sur chaque table d'un schéma exposé ^[7]. Une fois activée, la clé publique n'accède à rien tant que vous n'ajoutez pas de règles ^[7].
• Retirez les droits par défaut. Sur les projets qui les accordent encore par défaut, une nouvelle table publique démarre avec tous les privilèges déjà accordés aux rôles non connecté (anon) et connecté (authenticated), et l'ajout de règles ne les retire pas ^[7]. Révoquez-les et n'accordez de nouveau que ce dont chaque rôle a besoin ^[7].
• Écrivez des règles par utilisateur. Une règle pour une table privée doit correspondre à l'identifiant de l'utilisateur connecté, et pas simplement autoriser toute personne connectée. Évitez les règles toujours vraies sur les tables sensibles ^[2].
• Gardez les clés secrètes côté serveur. La clé publishable de Supabase n'est sûre dans le navigateur que parce que les règles de ligne la limitent ; les clés secret et service_role contournent toutes les règles et doivent rester dans le code serveur ou des variables d'environnement sécurisées ^[6].
• Remplacez les clés exposées. Si une clé secrète a déjà atteint le navigateur ou un dépôt de code public, remplacez-la et désactivez celle qui a été compromise, comme le conseille le guide des clés de Supabase ^[6].

Au 15 novembre 2026, la documentation de Supabase indique que les anciennes clés anon et service_role sont abandonnées d'ici fin 2026 au profit des clés publishable et secret ^[8]. Les nouvelles clés secret renvoient une erreur (HTTP 401) lorsqu'elles sont utilisées dans un navigateur, mais une clé exposée peut encore servir depuis d'autres outils ^[6][8]. Migrer maintenant est l'occasion de revoir chaque clé utilisée par une app.

Les scanners de sécurité intégrés détectent-ils tout ?

Non : les scanners des plateformes aident, mais plusieurs études montrent qu'ils ratent les règles les plus importantes ^[1][2][5].

En 2025, les chercheurs à l'origine de la CVE-2025-48757 ont constaté que le scanner de Lovable vérifiait seulement l'existence d'une règle de ligne, pas sa justesse ^[1]. Leur avis ajoute que le contrôle de publication de Lovable signale les tables sans règles, mais n'indique pas si les règles sont assez strictes ^[2]. Une règle ouverte passe un tel contrôle.

L'étude ACM le montre chiffres à l'appui : une part modeste de règles ouvertes, 6,3 % sur six outils, laissait malgré tout 56,9 % des dépôts avec au moins une table exposée, car une seule règle ouverte suffit ^[5]. Les auteurs ont publié un vérificateur gratuit qui signale ces règles avant le commit ^[5].

Utilisez les scanners comme premier filtre, puis faites vous-même les tests à deux comptes et en mode déconnecté. Le tableau ci-dessous résume les chiffres.

Peut-on utiliser sans risque des apps créées en vibe coding par d'autres ?

Soyez prudent avec tout ce qui demande des données personnelles, de santé ou de paiement, car les utilisateurs ne voient pas comment une app les protège ^[3][4]. Escape a trouvé des dossiers médicaux et des IBAN (identifiants de compte bancaire) parmi les données exposées ^[3].

Quelques habitudes simples réduisent le risque. Utilisez un mot de passe unique pour chaque nouvelle app, afin qu'une fuite n'en ouvre pas d'autres ; le guide Pouyam Password Managers Explained: How They Work and Whether They Are Safe explique comment. Ne partagez que les données nécessaires et préférez les pages de paiement de prestataires connus aux formulaires intégrés à l'app.

La responsabilité principale revient aux créateurs. Si vous publiez une app qui stocke les données d'autres personnes, faites les vérifications ci-dessus avant le lancement et après chaque changement important, car une seule nouvelle fonction peut rouvrir une faille refermée ^[4][5].