Qu'est-ce que la sécurité du vibe coding ?

En février 2025, Andrej Karpathy, co-fondateur d'OpenAI, a publié sur X : "Il y a un nouveau type de programmation que j'appelle 'vibe coding', où vous vous laissez complètement porter par l'ambiance, vous embrassez les exponentielles, et vous oubliez que le code existe." Le terme a immédiatement décollé — le dictionnaire Collins l'a désigné mot de l'année 2025.

Des outils comme Lovable, Bolt.new, Cursor, Replit et v0 permettent désormais à n'importe qui de construire des applications full-stack en quelques heures grâce à des prompts en langage naturel. Aucun diplôme en informatique requis. Livrez avant la fin de la journée.

Mais il y a un problème que la plupart des vibe coders découvrent trop tard : le code généré par l'IA est livré avec des vulnérabilités de sécurité sérieuses et bien documentées. Pas des vulnérabilités théoriques — des vulnérabilités qui ont déjà exposé les données de centaines de milliers d'utilisateurs réels.

La sécurité du vibe coding est la pratique qui consiste à identifier, comprendre et corriger les failles de sécurité introduites par les outils de codage IA. Ce guide couvre ce que la recherche démontre, ce que les incidents réels prouvent, et comment protéger votre application.

Les preuves : pourquoi le vibe coding crée des risques de sécurité

Ce n'est pas de la spéculation. Plusieurs études indépendantes et des incidents réels dressent un tableau clair.

Ce que la recherche démontre

Escape.tech (2025) a analysé 5 600 applications vibe-codées accessibles publiquement et a découvert :

Les plateformes analysées comprenaient Lovable (~4 000 apps), Base44, Create.xyz et Bolt.new.

Apiiro (2025) a suivi 7 000 développeurs à travers 62 000 repositories et a constaté :

Les développeurs utilisant l'IA exposaient des identifiants cloud près de deux fois plus souvent que ceux codant manuellement.

CSO Online / InfoWorld (décembre 2025) a évalué cinq outils majeurs de vibe coding — Claude Code, OpenAI Codex, Cursor, Replit et Devin — en construisant les trois mêmes applications de test avec chacun. Résultat : 69 vulnérabilités à travers 15 apps, avec des schémas tellement récurrents que les chercheurs ont conclu que le problème est structurel, pas accidentel.

La cause profonde

Lorsque vous demandez à une IA de "construire un SaaS avec l'authentification Supabase et les paiements Stripe", elle livrera une application fonctionnelle. Mais sous le capot, cette application aura probablement des API keys exposées, des règles de sécurité de base de données manquantes et aucun en-tête de sécurité — car rien de tout cela n'est nécessaire pour que l'application fonctionne.

Incidents réels : quand le vibe coding tourne mal

CVE-2025-48757 : 170+ applications Lovable exposées

En 2025, le chercheur en sécurité Matt Palmer a découvert que les projets générés par Lovable étaient systématiquement livrés sans Supabase Row Level Security (RLS).

L'ampleur : 303 endpoints à travers 170 projets étaient accessibles à des attaquants non authentifiés, qui pouvaient lire, modifier et supprimer toutes les données des bases de données affectées.

L'incident Moltbook (janvier 2026)

Moltbook, un "réseau social pour agents IA" construit avec des outils de vibe coding, a été lancé le 28 janvier 2026. En trois jours, il a été compromis.

Une base de données Supabase mal configurée avec RLS jamais activé a exposé toutes les données directement sur l'internet public.

18 697 étudiants exposés (février 2026)

En février 2026, The Register a rapporté qu'une application d'examen construite avec Lovable avait exposé les données de 18 697 utilisateurs, incluant des étudiants et des enseignants de grandes universités américaines. Le chercheur en sécurité a trouvé 16 vulnérabilités — dont six classées critiques.

Les vulnérabilités les plus courantes du vibe coding

Sur la base des recherches publiées et des incidents ci-dessus, voici les vulnérabilités qui apparaissent de manière récurrente :

1. Supabase Row Level Security (RLS) manquant

Sévérité : Critique — C'est la vulnérabilité n°1 de l'écosystème du vibe coding.

Supabase est le backend le plus populaire pour les applications vibe-codées, en particulier sur Lovable. Par défaut, RLS est désactivé sur les nouvelles tables. Cela signifie que quiconque connaît votre URL Supabase et votre anon key — toutes deux présentes dans votre JavaScript côté client par conception — peut lire, écrire et supprimer toutes les données de cette table.

Selon les recherches, 83 % des bases de données Supabase exposées impliquent des erreurs de configuration RLS. C'est ce qui a causé CVE-2025-48757, la fuite de Moltbook et l'exposition des données de 18 000 étudiants.

Pourquoi l'IA l'ignore : Activer RLS nécessite d'écrire des politiques PostgreSQL — une complexité supplémentaire qui n'affecte pas le fonctionnement de l'application. L'IA optimise pour une démo fonctionnelle, pas pour la sécurité en production.

La correction : Rendez-vous dans votre tableau de bord Supabase. Activez RLS sur chaque table. Écrivez des politiques qui restreignent l'accès en fonction de auth.uid(). Testez en essayant de requêter des données sans authentification — cela doit échouer.

2. API Keys et secrets exposés

Sévérité : Critique

L'étude Escape.tech a trouvé 400+ secrets exposés à travers 5 600 applications vibe-codées. Il ne s'agit pas seulement des anon keys Supabase (qui sont conçues pour être publiques lorsqu'elles sont combinées avec RLS). On y trouve :

• Des API keys OpenAI (facturées directement au développeur)
• Des clés secrètes Stripe (permettant des paiements non autorisés)
• Des clés SendGrid/Resend (permettant l'envoi de spam depuis votre compte)
• Des chaînes de connexion à la base de données avec accès en écriture complet

Les outils d'IA placent ces clés directement dans le code car les tutoriels et la documentation les présentent ainsi par souci de simplicité. L'IA reproduit le schéma.

La correction : Déplacez tous les secrets dans des variables d'environnement (.env.local). N'importez jamais de clés secrètes dans du code côté client. Utilisez le préfixe NEXT_PUBLIC_ uniquement pour les valeurs réellement publiques.

3. En-têtes de sécurité manquants

Sévérité : Élevé

Les en-têtes de sécurité indiquent aux navigateurs comment traiter votre contenu. Sans eux, votre application est vulnérable aux :

• Cross-Site Scripting (XSS) — les attaquants injectent des scripts malveillants
• Clickjacking — votre application est intégrée dans une iframe malveillante
• MIME sniffing — les navigateurs interprètent mal les types de fichiers
• Rétrogradation de protocole — sans HSTS, le HTTPS peut être contourné

La plupart des applications vibe-codées sont déployées sur Vercel, Netlify ou Railway avec zéro en-tête personnalisé. La plateforme d'hébergement ne les ajoute pas par défaut.

La correction : Ajoutez ces en-têtes à la configuration de votre hébergement (ex. vercel.json ou next.config.ts) :

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()

4. Configuration Firebase non sécurisée

Sévérité : Élevé

Les règles de sécurité par défaut de Firebase permettent à n'importe qui de lire et écrire dans votre base de données entière :

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

Les outils d'IA déploient avec ces valeurs par défaut car écrire des règles adéquates nécessite de comprendre votre modèle de données — un contexte difficile à déduire d'un prompt en langage naturel.

La correction : Écrivez des règles granulaires pour chaque collection. Utilisez Firebase Authentication pour valider les utilisateurs. Testez avec le Firebase Emulator avant de déployer.

5. Failles de logique d'authentification

Sévérité : Élevé

L'incident Lovable de février 2026 a révélé quelque chose de profondément préoccupant : l'IA a écrit une authentification qui inversait le contrôle d'accès — bloquant les utilisateurs authentifiés tout en autorisant les non authentifiés. Ce n'était pas un contrôle manquant ; c'était un contrôle qui faisait l'exact inverse de ce qui était prévu.

L'étude de CSO Online a confirmé que si l'IA gère bien les schémas basiques (requêtes paramétrées, prévention XSS au niveau du framework), elle échoue sur la logique de sécurité dépendante du contexte — comme déterminer quels utilisateurs devraient accéder à quelles ressources.

La correction : Vérifiez manuellement toute la logique d'authentification et d'autorisation. Testez chaque route protégée avec et sans identifiants valides. Ne faites jamais confiance au code d'authentification généré par l'IA sans vérification.

6. Fichiers sensibles exposés

Sévérité : Élevé

Les applications vibe-codées exposent fréquemment des fichiers qui ne devraient jamais être publics : fichiers .env, répertoires .git/, package.json, fichiers de sauvegarde. L'étude Escape.tech a trouvé 175 instances de données personnelles exposées à travers ces fichiers.

La correction : Configurez correctement votre .gitignore. Bloquez l'accès aux fichiers dot dans la configuration de votre serveur web. Testez en accédant à votredomaine.com/.env dans un navigateur — cela doit renvoyer une erreur 404.

7. Dépendances vulnérables

Sévérité : Moyen à Élevé

Les outils d'IA suggèrent des packages basés sur des données d'entraînement qui peuvent être antérieures aux correctifs de sécurité. L'étude Apiiro a montré que le développement assisté par IA conduit à davantage de vulnérabilités dans toutes les catégories — y compris les dépendances open-source.

La correction : Exécutez npm audit après chaque installation. Configurez Dependabot ou Snyk pour des alertes automatisées. Supprimez les packages inutilisés.

8. Server-Side Request Forgery (SSRF)

Sévérité : Moyen à Élevé

L'évaluation de CSO Online a révélé que si les outils d'IA gèrent bien les classes de vulnérabilités "résolues" (SQL injection, XSS basique), ils échouent sur les problèmes dépendants du contexte comme le SSRF. Comme l'ont noté les chercheurs : "Il n'existe aucune règle universelle pour distinguer les requêtes URL légitimes des malveillantes."

La correction : Validez et assainissez toutes les URL fournies par les utilisateurs. Maintenez des listes blanches pour les services externes. Ne transmettez jamais les données utilisateur directement à des appels fetch côté serveur.

Comment sécuriser votre application vibe-codée

Étape 1 : Scannez votre application

Avant de pouvoir corriger des problèmes, vous devez les trouver. Utilisez un scanner de sécurité qui vérifie les vulnérabilités spécifiques créées par le vibe coding — pas seulement les problèmes de sécurité web génériques.

Étape 2 : Corrigez d'abord les problèmes critiques

Priorisez par impact :

1. Activez Supabase RLS sur toutes les tables (cela seul aurait empêché CVE-2025-48757)
2. Supprimez les clés secrètes exposées du code côté client
3. Verrouillez les règles Firebase si applicable
4. Vérifiez la logique d'authentification — testez-la manuellement, ne faites pas confiance à l'IA

Étape 3 : Ajoutez les en-têtes de sécurité

Cinq minutes de configuration qui bloquent des catégories entières d'attaques. Copiez les en-têtes ci-dessus dans la configuration de votre hébergement.

Étape 4 : Mettez à jour les dépendances

npm audit
npm audit fix

Supprimez les packages que vous n'utilisez pas. Chaque dépendance est une surface d'attaque supplémentaire.

Étape 5 : Mettez en place une surveillance continue

La sécurité n'est pas une correction ponctuelle. De nouvelles vulnérabilités apparaissent lorsque vous mettez à jour le code, ajoutez des fonctionnalités ou modifiez des configurations.

• Scans programmés — minimum hebdomadaire
• Surveillance des dépendances — Dependabot, Snyk ou Renovate
• Re-scan après chaque déploiement

Sécurité du vibe coding par plateforme

Lovable

La plateforme la plus étudiée en matière de sécurité du vibe coding. CVE-2025-48757 ciblait directement les projets générés par Lovable. Risques principaux : Supabase RLS manquant, anon keys exposées sans politiques appropriées, aucun en-tête de sécurité. Lovable a lancé une fonctionnalité "security scan" dans Lovable 2.0, mais les chercheurs ont constaté qu'elle ne détecte que la présence de RLS — pas si les politiques fonctionnent réellement.

Bolt.new

Inclus dans l'échantillon de l'étude Escape.tech. Problèmes courants : API keys codées en dur, gestion minimale des erreurs qui révèle des détails internes, configurations CORS permissives.

Cursor

La vulnérabilité CurXecute (2025) a montré que Cursor lui-même pouvait être exploité pour exécuter des commandes arbitraires sur la machine d'un développeur via un serveur MCP malveillant. Pour le code généré : packages suggérés par l'IA avec des CVE connues, schémas de sécurité incohérents entre les fichiers, identifiants de test laissés en production.

Replit

Le déploiement instantané signifie que les applications sont mises en ligne avant toute revue de sécurité. Les variables d'environnement peuvent fuiter via le mécanisme de fork public de Replit. L'absence de rate limiting est quasi universelle.

v0 (Vercel)

Génère des composants frontend généralement plus sûrs. Mais lorsqu'ils sont combinés avec des services backend : routes API sans middleware d'authentification, server actions sans validation des entrées, requêtes de base de données non protégées.

La checklist de sécurité du vibe coding

Avant le lancement

• Scanner avec un outil de sécurité (ScanVibe, ou similaire)
• Activer RLS sur toutes les tables Supabase avec des politiques appropriées
• Écrire des règles Firebase adéquates (si vous utilisez Firebase)
• Déplacer tous les secrets dans des variables d'environnement
• Ajouter les 6 en-têtes de sécurité essentiels
• Vérifier SSL/TLS et HSTS
• Exécuter npm audit et corriger les problèmes critiques
• Tester manuellement l'authentification — connexion, inscription, routes protégées
• Vérifier que .env et .git/ ne sont pas accessibles via le navigateur
• Tester les endpoints API sans authentification (doivent renvoyer 401/403)
• Vérifier la configuration CORS

Après le lancement

• Scans de sécurité hebdomadaires
• Surveillance des mises à jour de dépendances
• Re-scan après chaque déploiement
• Surveiller les schémas d'accès inhabituels à la base de données

Questions fréquentes

Qu'est-ce que le vibe coding ?

Le vibe coding consiste à construire des logiciels en décrivant ce que vous souhaitez en langage naturel à des outils d'IA comme Lovable, Bolt.new, Cursor, Replit et v0. L'IA génère le code, et vous l'acceptez sans examiner en profondeur l'implémentation. Le terme a été inventé par Andrej Karpathy en février 2025 et a été désigné mot de l'année 2025 par le dictionnaire Collins.

Le vibe coding est-il sûr ?

Le code produit par le vibe coding contient souvent des vulnérabilités de sécurité. Une évaluation de décembre 2025 a trouvé 69 vulnérabilités à travers 15 applications construites avec les principaux outils de vibe coding. Cependant, avec un scanner de sécurité adéquat et une revue manuelle, les applications vibe-codées peuvent être sécurisées pour un usage en production.

Quels sont les plus grands risques de sécurité ?

D'après les recherches publiées : le Supabase RLS manquant (à l'origine de CVE-2025-48757, affectant 170+ apps), les API keys et secrets exposés (400+ trouvés dans 5 600 apps par Escape.tech), les en-têtes de sécurité manquants, les failles de logique d'authentification et les dépendances vulnérables. L'étude Apiiro a montré que le code assisté par IA introduit plus de 10 000 nouvelles failles de sécurité par mois.

Comment vérifier si mon application vibe-codée est sécurisée ?

Scannez-la avec un outil conçu pour les applications construites par IA. ScanVibe vérifie 8 catégories de sécurité — SSL, en-têtes, secrets, bibliothèques, fichiers exposés, Supabase, Firebase et endpoints d'authentification — en moins de 30 secondes. Gratuit, aucune inscription nécessaire.

Puis-je rendre mon application Lovable/Bolt prête pour la production ?

Oui, mais cela nécessite un travail de sécurité manuel. Les trois applications Lovable avec une bonne sécurité dans l'étude Escape.tech avaient toutes des développeurs qui ont manuellement vérifié et renforcé le code généré par l'IA. Activez RLS, ajoutez des en-têtes, supprimez les clés exposées, vérifiez la logique d'authentification.

À quelle fréquence dois-je scanner ?

Après chaque déploiement, au minimum. Des scans programmés hebdomadaires sont idéaux. L'étude Apiiro a montré que le volume de vulnérabilités introduites par l'IA s'accélère, il ne se stabilise pas — une surveillance continue est donc essentielle.

Sources

Les données de cet article proviennent de :

• Escape.tech — "The State of Security of Vibe Coded Apps" (5 600 apps analysées)
• Apiiro — "4x Velocity, 10x Vulnerabilities" (7 000 développeurs, 62 000 repos)
• Stanford University — "Do Users Write More Insecure Code with AI Assistants?" (évalué par des pairs)
• CSO Online — "Output from vibe coding tools prone to critical security flaws" (décembre 2025)
• CVE-2025-48757 — National Vulnerability Database (vulnérabilité RLS Lovable)
• The Register — "AI-built app on Lovable exposed 18K users" (février 2026)

Commencez à sécuriser votre application dès aujourd'hui

Chaque incident ci-dessus a commencé de la même manière : quelqu'un a déployé du code généré par l'IA sans le vérifier. La fuite de Moltbook a pris trois jours. L'exposition des données étudiantes a affecté 18 697 personnes. CVE-2025-48757 a touché 170+ applications d'un seul coup.

La correction commence par savoir où vous en êtes.

Scannez votre application gratuitement avec ScanVibe — Note de sécurité A-F en 30 secondes.

Votre IA a écrit le code. Assurons-nous qu'il est sûr.