--- title: "Risques de sécurité du vibe coding : 5 failles reproduites" description: "Ce qui tourne mal dans les apps générées par vibe coding, avec les chiffres de trois études et cinq failles d'accès reproduites sur un Supabase local." url: "https://madsalt.tech/fr/blog/vibe-coding-security-risks/" author: "Denys Zaichenko" language: "fr" published: 2026-10-24 --- # Risques de sécurité du vibe coding : 5 failles reproduites En bref Le code qu'écrit une IA tourne en général. Ce qui échoue, c'est qui peut atteindre les données. Dans un audit de 2026 portant sur 200 applications vibe-codées déployées, 91 % avaient au moins une vulnérabilité, et le contrôle d'accès défaillant était le groupe le plus important. J'ai reproduit cinq de ces failles d'accès sur un Supabase local : avec la seule clé publique, une table sans RLS, une politique toujours vraie, une vue et une clé secrète divulguée ont chacune rendu les 3 lignes sur 3. Vérifiez d'abord votre application sur ces points. Je suis Denys, ingénieur full-stack et IA. Je répare des applications construites avec Lovable, Bolt, Cursor ou Claude Code, et la plupart tournent sur Supabase. Cet article rassemble ce que dit la recherche publiée sur la sécurité du vibe coding, et ce que j'ai vu en reconstruisant exprès les erreurs courantes. ## Quels sont les risques de sécurité du vibe coding ? Le risque principal est le contrôle d'accès défaillant : des données que n'importe quel visiteur peut lire ou modifier, parce que la règle censée l'arrêter manque, est trop lâche ou est contournée. Viennent ensuite l'injection et l'authentification faible. Trois études indépendantes vont dans le même sens : | Étude | Ce qui a été testé | Ce qu'elle a trouvé | | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Deng, Fan et Meng, arXiv 2606.23130](https://arxiv.org/abs/2606.23130), juin 2026 | 200 applications déployées, construites avec Claude Code et Lovable, auditées à la main et par des agents | 182 applications sur 200 (91 %) avaient au moins une vulnérabilité ; 65,77 % des 1 186 constats étaient Critical ou High ; le contrôle d'accès défaillant était la première catégorie, dans 64 % des applications | | [Escape](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/), octobre 2025 | 5 600 applications publiques de Lovable, Base44, Create.xyz et d'autres, scan passif | Plus de 2 000 vulnérabilités à fort impact, plus de 400 secrets exposés, 175 cas de données personnelles exposées ; la cause principale était des permissions mal configurées, surtout la RLS de Supabase | | [Veracode GenAI Code Security Report](https://www.veracode.com/resources/analyst-reports/2026-genai-code-security-report/), 2025 et 2026 | 80 tâches de programmation confiées à plus de 100 modèles | Seules 55 % des tâches ont produit du code sûr en 2025 ; le taux moyen de réussite était de 56 % en 2026, stable quelle que soit la taille des modèles et l'année | Les études mesurent des choses différentes, les pourcentages ne s'additionnent donc pas en un seul chiffre. Ce qu'elles partagent, c'est la forme : le code fonctionne, et les failles se trouvent à la frontière de confiance. ## Quelles failles ai-je reproduites ? J'ai créé une table `orders` avec trois lignes de faux clients sur un Supabase local (CLI 2.109.1, Postgres 17.6, PostgREST 14.14). Puis j'ai appelé la Data API comme le fait un navigateur, avec la publishable key que tout frontend Supabase livre, en ne changeant qu'une seule chose à la fois. ![Ce qu'une clé publique a obtenu d'une table. Supabase local, 3 lignes de fausses commandes, une requête chacune. Table sans RLS: Publishable key → orders, RLS désactivée → 3 lignes sur 3; RLS activée, pas de politique: Publishable key → orders, RLS activée → 0 ligne; Politique using (true): Publishable key → using (true) → 3 lignes sur 3; Vue sans security_invoker: Publishable key → vue order_summary → 3 lignes sur 3; Secret key dans le code du navigateur: Secret key → BYPASSRLS → 3 lignes sur 3.](https://madsalt.tech/charts/fr/vibe-coding-security-risks.svg) *Figure 1. Ma reproduction sur un stack Supabase local (Postgres 17.6, PostgREST 14.14), 23 octobre 2026.* | Configuration | Ce que la clé publique a obtenu | Pourquoi | | ----------------------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------- | | Table sans RLS | Les 3 lignes, et une insertion a répondu `201 Created` | Les droits par défaut laissent `anon` lire et écrire, et rien ne filtre les lignes | | RLS activée, aucune politique | `[]`, une liste vide | La RLS sans politique refuse tout à `anon` et `authenticated` | | Politique `using (true)` | Les 3 lignes | La politique existe, la table semble donc protégée, mais elle autorise chaque ligne | | Vue sur la table protégée | Les 3 lignes | Une vue s'exécute avec les droits de son propriétaire sauf si elle a `security_invoker = true` ; avec, on obtient `[]` | | Secret key dans le code du frontend | Les 3 lignes | La secret key correspond à `service_role`, qui a `BYPASSRLS` | La deuxième ligne est le moment dangereux. La RLS est activée et l'application affiche une liste vide : elle semble cassée. Le prompt le plus rapide qui la « répare » est une politique qui autorise tout, c'est-à-dire la troisième ligne. Cette boucle, une erreur puis une correction qui élargit l'accès, est le schéma que je rencontre le plus dans les applications vibe-codées, et c'est pourquoi « la RLS est activée » dit peu à lui seul. ## Pourquoi le code écrit par l'IA échoue-t-il sur le contrôle d'accès ? Un agent est récompensé pour du code qui tourne. Une liste vide ou un `401` ressemble à un bug, et la correction qui le fait disparaître est souvent celle qui ouvre l'accès. L'étude arXiv rattache ses 1 186 constats à huit modes de défaillance récurrents, regroupés en défauts de mémoire, d'objectif et de connaissance des agents, et elle a constaté qu'un meilleur prompt réduisait le nombre de failles sans les supprimer. La deuxième raison est l'architecture. Une application Lovable ou Bolt n'a généralement pas de backend propre : le navigateur parle directement à la base via la Data API. Chaque règle qui protège les données clients doit vivre dans Postgres, sous forme de droits, de politiques et de fonctions, et rien de tout cela n'est visible dans l'aperçu de l'application, où vous êtes connecté en tant que propriétaire. Supabase change un réglage par défaut ici : à partir du [30 octobre 2026](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically), les nouvelles tables des projets existants ne reçoivent plus automatiquement de droits pour la Data API. Sur mon stack, une table sans ce droit a répondu `42501 permission denied` avec un indice qui nomme le `GRANT` manquant. Cela arrête la première ligne du tableau ci-dessus pour les nouvelles tables, mais pas les quatre autres, ni les tables qui existent déjà. ## Qu'est-ce qui tourne encore mal en dehors de la base ? Les mêmes études listent des risques qui n'ont rien à voir avec la RLS : - **Des secrets dans le bundle.** Escape a trouvé plus de 400 secrets exposés, dont des clés OpenAI et des clés d'administration de paiement. Tout ce qui est livré au navigateur est public. - **Des garde-routes seulement dans React.** Une page qui redirige les utilisateurs déconnectés a quand même une API derrière elle qui répond à tout le monde. - **Des limites de débit qui ne se déclenchent jamais.** Sur un projet Supabase hébergé que j'ai sondé, un compteur gardé en mémoire dans une edge function était remis à zéro à chaque requête. Je l'ai décrit dans ma [checklist de sécurité d'une application Lovable](https://madsalt.tech/fr/blog/lovable-app-security-checklist/). - **De vieilles bibliothèques.** Escape a compté 254 instances de bibliothèques JavaScript vulnérables dans des ressources publiques, souvent héritées de modèles. ## Comment vérifier une application vibe-codée ? 1. Ouvrez l'application, puis DevTools → Network, et repérez les requêtes vers `/rest/v1/`. Copiez-en une en cURL, retirez l'en-tête `Authorization`, gardez `apikey`, et exécutez-la. Si des données reviennent, elles reviennent pour tout le monde. 2. Cherchez dans le JavaScript compilé `sb_secret_` et `service_role`. Un résultat est une clé à renouveler aujourd'hui. 3. Lancez l'[audit de sécurité Supabase](https://madsalt.tech/fr/tools/supabase-security-check/) gratuit. Il lit le catalogue du projet et signale, parmi ses 46 règles, « RLS désactivé sur des tables exposées », « Politiques qui autorisent toutes les lignes », « Vues qui contournent RLS » et « Privilèges par défaut qui ouvrent les nouveaux objets à l’API » : les quatre premières lignes du tableau ci-dessus. 4. Testez avec deux utilisateurs dans deux entreprises, le seul test qu'un scanner ne peut pas faire à votre place. Ma façon de procéder est dans la [checklist Lovable](https://madsalt.tech/fr/blog/lovable-app-security-checklist/), et [comment tester Supabase RLS](https://madsalt.tech/fr/blog/how-to-test-supabase-rls/) montre la méthode sur une application en production dotée d'un écran de permissions. ```bash curl 'https://.supabase.co/rest/v1/orders?select=*' \ -H 'apikey: ' ``` ## Ce que cela ne montre pas Ma reproduction est une table sur un stack local, construite pour montrer chaque mécanisme, pas un scan d'applications réelles. Les chiffres de prévalence viennent des trois études, chacune avec son échantillon et sa méthode, liées plus haut. Et un résultat propre sur ces cinq contrôles ne rend pas une application sûre : les bugs de logique, comme un garde-fou qui laisse passer une valeur manquante, demandent leurs propres tests. L'un d'eux est dans [un NULL qui a sauté un contrôle de permission](https://madsalt.tech/fr/notes/plpgsql-if-not-null-fails-open/). Application construite avec un outil d'IA ? Je compare volontiers nos façons de procéder pour savoir quoi vérifier d'abord. Sans démarchage. [Me contacter](https://madsalt.tech/fr/#contact)