Sécurité du vibe coding : la checklist de trente minutes qui sépare une app lancée d'un data leak

Le 28 janvier 2026, Moltbook se présentait comme “the front page of the agent internet” et son fondateur revendiquait publiquement n’avoir “pas écrit une seule ligne de code”. Trois jours plus tard, Wiz Research découvrait que la clé Supabase était hardcodée dans le JavaScript client et que Row Level Security n’avait jamais été activé : 1,5 million de tokens d’authentification, 35 000 emails, plus de 17 000 handles Twitter, et des conversations privées contenant des clés OpenAI en clair, librement accessibles à qui ouvrait sa DevTools. Moltbook n’est pas une exception isolée. C’est la version la plus récente d’un pattern qui s’est documenté à l’échelle dans les dix-huit derniers mois, et qui définit aujourd’hui une catégorie de risque que ni les frameworks ni les agents ne corrigent par défaut : l’app vibe-codée qui est techniquement fonctionnelle et juridiquement explosive.

La défense n’est pas paranoïaque. C’est une checklist de trente minutes, en cinq sections, qu’on lance avant chaque déploiement. Voici la version raisonnée, celle qui intègre la jurisprudence française récente, le contexte CNIL, et les leçons que les incidents publics nous ont déjà servies.

Ce que les incidents de 2025-2026 ont vraiment montré

Avant la checklist, le contexte qui la justifie. Trois incidents publics dessinent le pattern.

Mars 2025, l’écosystème Lovable. Le chercheur Matt Palmer scanne 1 645 applications construites avec Lovable et découvre que 170 d’entre elles, environ 10 %, partagent la même vulnérabilité : Supabase configuré sans RLS, clé anon exposée côté client, lecture intégrale de la base depuis le navigateur. La faille reçoit le CVE-2025-48757 avec un score CVSS de 9,3 (critique). Soixante-neuf jours s’écoulent entre la déclaration et la publication CVE, pendant ce temps, les utilisateurs des apps concernées ne sont pas notifiés.

Janvier-février 2026, Moltbook. Le scénario complet : fondateur revendiquant zéro ligne de code, clé Supabase dans le bundle frontend, RLS non configuré, exposition de 1,5 million de credentials. L’incident est emblématique parce qu’il aligne parfaitement tous les marqueurs du genre, y compris le ratio agent/humain de 88 pour 1 que l’analyse de la base révèle après coup, suggérant que l’engagement organique était lui-même fabriqué.

Mai 2026, étude RedAccess. L’enquête israélienne, reprise en France par Stéphane Larue et internationalement par Wired et Axios, scanne les sous-domaines publics de Lovable, Replit, Base44 et Netlify. Résultat : 380 000 apps accessibles, dont près de 40 % exposent des données critiques en accès direct sans authentification. Sur le sous-ensemble : plannings d’équipe hospitalière avec noms et téléphones, stratégies go-to-market d’entreprises, historiques complets de conversations client, documents comptables. Les URLs précises ont été retenues par RedAccess et ses partenaires médias pour ne pas faciliter l’exploitation, limite épistémique honnête, mais le volume est mesuré.

Le pattern, à travers les trois incidents, est répétable et ennuyeux : Supabase + RLS désactivé + clé secrète dans le frontend + endpoints non rate-limités. La checklist qui suit traite ce pattern dans son ordre d’urgence.

Étape 1, Cadrage légal (10 minutes)

C’est l’étape qu’on saute parce qu’elle ne touche pas au code. C’est aussi celle qui transforme un incident technique en procès.

Trois choses, minimum, avant de collecter le premier email :

Une politique de confidentialité réelle, même générée. Termly ou un template adapté font le travail en cinq minutes. Le format importe moins que le fait d’avoir un texte qui décrit ce que vous faites avec les données, et qui correspond effectivement à ce que vous faites.

Savoir où vivent les données. Région Supabase, région Vercel, services tiers qui touchent les données. C’est aussi l’angle RGPD : si vos données utilisateurs européens vivent dans us-east-1, vous devez avoir le DPA (Data Processing Agreement) signé avec votre fournisseur, Supabase, par exemple, propose un DPA pré-signé qu’on peut télécharger en deux minutes.

Pas de pratique douteuse. Pas de revente, pas d’export sur boîte personnelle, pas de mots de passe en clair. Pas perfection, juste pas-imprudent.

Pour les builders français, le contexte juridique est explicite. Le Guide RGPD du développeur publié par la CNIL demande, sur les bases, “l’utilisation d’identifiants uniques et propres à chaque individu”, le déploiement “du protocole TLS version 1.2 ou 1.3 sur tous les sites web et pour les transmissions”, et la documentation des flux de données “en amont du projet”. Ce ne sont pas des suggestions, c’est ce que l’autorité de contrôle attend en cas d’audit. Et les amendes du RGPD plafonnent à 4 % du chiffre d’affaires annuel mondial ou 20 millions d’euros, le plus élevé des deux.

C’est dix minutes pour passer d’un “j’ai oublié” à un “je peux montrer”. La différence en cas d’audit CNIL est sans commune mesure.

Étape 2, Verrouiller la base de données

C’est le terrain où les incidents publics se produisent. Trois contrôles, par ordre de criticité.

Row Level Security sur Supabase. Sans RLS, ouvrir la DevTools du navigateur et taper une requête suffit à lire la base intégrale. Pas hacker, pas exploit, juste taper la requête. La fiche pratique d’écosystème côté français pose le constat brutalement : 70 % des apps Supabase auditées par Drakkar n’ont pas de règles RLS configurées. Aller dans le dashboard Supabase → Authentication → Policies. Si vous voyez zéro policy, votre app est nue. Si vous utilisez Lovable ou Bolt, demandez à l’agent d’activer RLS et de générer les policies pour chaque table, le SQL se produit en quelques secondes.

Validation côté serveur sur chaque formulaire. Zod côté client n’est pas de la sécurité, c’est de l’UX. Un attaquant désactive le JavaScript, ouvre Postman, et envoie ce qu’il veut directement à l’API. Si votre seule validation est dans le navigateur, vous n’avez pas de validation du tout. La règle : re-valider sur le serveur. Types, longueurs, sanitization. Pas négociable.

Messages d’erreur qui ne fuient pas. “SELECT * FROM users WHERE email failed” en réponse HTTP, c’est offrir à l’attaquant votre schéma de table et le nom de vos colonnes. “Utilisateur introuvable” fait le même travail UX sans rien révéler. Logger l’erreur complète côté serveur avec contexte, montrer un message générique à l’utilisateur, jamais de stack trace en production. Sécurité opérationnelle de base que la majorité des MVP ratent dès le premier jour.

Le test pratique pour vérifier RLS : se connecter avec deux comptes différents, et tenter d’accéder aux données de l’un depuis l’autre. Si ça passe, votre RLS est mal écrite. Activer RLS sans tester est pire que ne rien activer parce que ça crée une fausse confiance.

Étape 3, Tester les cas d’échec d’authentification

La majorité des développeurs testent uniquement le happy path. L’authentification casse là où elle est moins testée, et c’est exactement où les attaquants commencent leur reconnaissance.

Quatre tests, à passer manuellement, en moins de dix minutes :

Cinq mots de passe incorrects de suite. Le compte se verrouille-t-il ? Le message renvoyé confirme-t-il l’existence de l’email ou reste-t-il générique ?
Reset de mot de passe pour un email inexistant. L’app révèle-t-elle que l’email n’est pas dans la base ?
Lien de vérification cliqué deux fois. L’app casse-t-elle l’état ou gère-t-elle gracieusement ?
Inscription avec un email déjà enregistré. Le message fuite-t-il l’existence d’un compte ?

Ces quatre tests, déroulés sur un projet vibe-codé typique, attrapent l’écrasante majorité des failles d’auth surface. Le point de vigilance, c’est qu’aucun de ces tests n’est dans le happy path d’un demo, donc personne ne les fait sans discipline explicite. Une checklist qu’on relit avant chaque release, ou un test automatisé qui rejoue ces quatre scénarios à chaque PR, est la forme opérationnelle de cette discipline.

Étape 4, Les quatre prompts d’audit IA

C’est la partie que Tomar a popularisée et qui mérite d’être intégrée comme un outil parmi d’autres, pas une solution finale. Quatre prompts à coller dans Claude Code, Cursor, ou l’agent de votre choix :

1. Review my app as a security specialist and make sure I have strong
   security headers and a solid baseline security posture.

2. Review my app against OWASP standards and highlight vulnerabilities.

3. Check my app for any credential or sensitive data leaks in frontend
   or API routes.

4. Ensure no API keys are exposed in frontend code or network calls.

Le deuxième prompt vaut la peine d’être pointé sur le standard OWASP qui couvre désormais l’IA : OWASP Top 10 for LLM Applications 2025 liste les dix catégories spécifiques aux apps qui appellent un LLM en production, prompt injection, sensitive information disclosure, supply chain, data poisoning, output handling, excessive agency, system prompt leakage, vector/embedding weakness, misinformation, unbounded consumption. C’est la lecture qu’aucune des checklists “vibe coding security” ne mentionne et qui doit pourtant cadrer la posture quand un LLM tourne dans la stack.

La limite à connaître. Les prompts IA attrapent les failles de surface, clés exposées, headers manquants, RLS désactivé. Ils ne voient pas la logique métier vulnérable, les bugs d’état d’auth complexes, ni les attaques d’injection sophistiquées. C’est un plancher, pas un plafond. Sur du code qui touche à la santé, à la finance, ou à toute donnée régulée, un audit de sécurité humain par-dessus reste obligatoire.

Étape 5, Protéger l’infrastructure

C’est l’étape qui protège votre portefeuille, pas seulement vos données.

Rate limits sur chaque endpoint qui appelle une API payante. OpenAI, Anthropic, Stripe, Resend, chaque route qui consomme du crédit doit avoir un plafond par utilisateur et par minute. Tomar raconte un cas concret de facture Supabase qui passe de 20 $ à 200 $ en une journée parce qu’un seul endpoint n’avait pas de limite. À l’échelle d’un MVP indé, c’est un mois de runway brûlé sans rien produire.

Caps absolus côté dashboard fournisseur. OpenAI et Anthropic permettent tous deux de configurer un plafond mensuel et des alertes à 50 % du budget. Activez-les. C’est la seule défense qui fonctionne quand votre code est compromis et qu’un attaquant utilise vos clés pour générer cinquante millions de tokens à votre compte.

CAPTCHA sur tout formulaire public. Cloudflare Turnstile est gratuit, respecte la vie privée, et s’intègre en dix minutes. Sans ça, les bots inondent un formulaire de contact en quelques heures dès qu’il est indexé. Les agences qui font des audits voient régulièrement des formulaires ayant collecté 500 soumissions de spam en une heure, parce que le builder pensait que CAPTCHA était optionnel pour son trafic.

CORS strict sur l’API. Par défaut, beaucoup de frameworks autorisent les requêtes depuis n’importe quel origin. Pour le dev, c’est commode ; pour la prod, c’est ouvert à la CSRF. Restreindre à votre domaine de production plus localhost de test, point.

Le scan intégré : votre dernier filtre avant deploy

Cursor, Claude Code, et Lovable ont tous intégré un scanner de sécurité qui tourne en continu. Il flag les misconfigurations RLS, les secrets exposés, les dépendances vulnérables, les patterns insecure. Le réflexe à entretenir : fixer tout ce qu’il flag avant deploy, sans exception. Le “je verrai plus tard” est exactement le mode qui crée la dette de sécurité qui compose ensuite plus vite que la dette technique.

C’est aussi la même logique que pour le moindre privilège qu’on applique aux modèles : la défense en profondeur fonctionne quand les couches sont toutes tenues, pas quand on choisit celles qui font moins de friction.

Pour les builders français : le réflexe RGPD spécifique

Le contexte français mérite un détour explicite parce que les builders d’apps européennes ont une couche réglementaire que les checklists américaines ne couvrent pas.

Lovable Academy a publié une checklist en dix points qui couvre, selon ses chiffres, 95 % des obligations RGPD pour un SaaS Lovable+Supabase en moins d’une soirée. Les points opérationnels qui s’ajoutent aux cinq sections américaines :

Désigner un DPO (Délégué à la Protection des Données), même informel, mettre son nom et son email en pied de politique.
Tenir le registre des traitements, modèle ODS téléchargeable sur le site de la CNIL.
MFA administrateur sur Supabase Auth, OTP ou Passkeys.
Signer le DPA Supabase, Data Processing Agreement pré-signé téléchargeable.
Bandeau cookies conforme aux règles CNIL de 13 mois maximum pour les traceurs d’audience.
Procédure de notification de violation, RGPD article 33 impose une notification dans les 72 heures. La pré-configurer (Zapier ou équivalent → Slack + email DPO) avant l’incident.

C’est aussi le bon moment pour rappeler que le RGPD ne dit pas “sauf si IA”. Si votre app collecte des données utilisateurs européens, le fait qu’elle ait été vibe-codée n’est pas une circonstance atténuante en cas de plainte CNIL. La responsabilité est sur vous, indépendamment de l’outil qui a écrit le code.

Ce que la checklist ne couvre PAS

L’honnêteté impose de nommer les angles morts.

Les prompts IA attrapent les failles de surface mais pas la logique métier. Un agent qui valide qu’on est bien soi pour modifier ses données ne voit pas qu’on peut, en passant un autre id dans le payload, modifier les données d’un autre. Ces failles d’auth contextuelle demandent un audit humain.

L’OWASP Top 10 LLM 2025 couvre les risques spécifiques aux apps qui exécutent un LLM. Une app vibe-codée qui appelle elle-même une API GPT en production est exposée à la prompt injection indirecte, un document utilisateur peut contenir des instructions cachées qui détournent le comportement de votre agent. C’est un terrain qu’aucune checklist Supabase ne couvre. C’est aussi le terrain que j’ai déjà cadré dans Le prompt est le nouveau périmètre, les apps qui ajoutent un LLM héritent d’un périmètre qu’elles n’avaient pas avant.

Et la dette de sécurité compose vite. Drakkar chiffre le multiplicateur à “2× à 5× le temps de dev par feature” sur un projet vibe-codé sans audit initial. C’est exactement le ratio qu’on retrouve en pratique sur les rebuilds en agence : ce qui aurait coûté trente minutes au lancement coûte trente jours en remédiation post-incident.

La règle qu’on emporte, même si on ne lit pas le reste

C’est la même règle que je posais dans J’ai livré une fonctionnalité IA le vendredi. Le lundi, c’était un risque juridique. : l’IA accélère ce qui marche et ce qui casse. Un MVP construit en un weekend par IA est un MVP qui ouvre, en un weekend, une surface de responsabilité juridique et technique qu’aucun framework ne ferme par défaut.

La checklist de trente minutes n’est pas un raffinement de PM senior. C’est le minimum opérationnel qui sépare un launch d’un procès. Pour les builders qui shippent en 2026, c’est aussi obligatoire que le déploiement lui-même, et le fait que ça tienne en une demi-heure n’est pas un argument pour la rapporter au prochain sprint.

Le test honnête, à passer juste avant de cliquer deploy : si quelqu’un ouvre la DevTools de votre app à minuit, peut-il lire la base ? si oui, ne déployez pas.

Si cela vous a parlé, vous aimerez J’ai livré une fonctionnalité IA le vendredi. Le lundi, c’était un risque juridique. et Secrets, outils, et l’agent qui a lu votre fichier env. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.