La faille Moltbook : Quand le codage par IA devient un cauchemar de sécurité

Que s'est-il réellement passé chez Moltbook ?

Laissez-moi vous expliquer exactement ce qui a mal tourné, car les détails comptent.

Moltbook a été créé avec Supabase — une alternative open source populaire à Firebase qui fournit des bases de données PostgreSQL hébergées. Supabase est devenu le backend de choix pour les applications créées avec le vibe coding car il gère l'authentification, les bases de données et le stockage avec une configuration minimale.

Le problème ? Quelqu'un (ou une certaine IA) a placé une clé API Supabase directement dans le code JavaScript côté client. C'est une erreur de sécurité fondamentale. Les clés API appartiennent au serveur, jamais dans le code qui s'exécute dans le navigateur de l'utilisateur.

Mais ça s'aggrave.

Cette clé API avait un accès complet en lecture et en écriture à l'ensemble de la base de données. Et Moltbook n'avait pas activé la sécurité au niveau des lignes (RLS) — une fonctionnalité Supabase qui contrôle qui peut accéder à quelles données. La RLS est aussi optionnelle qu'une ceinture de sécurité. Vous pensez peut-être ne pas en avoir besoin jusqu'à ce que vous vous écrasiez.

Les chercheurs en sécurité de Wiz ont trouvé la clé exposée en quelques minutes après avoir regardé le site web. Ils auraient pu :

• Téléchargé toutes les 1,5 million de clés API (y compris les clés pour OpenAI, Anthropic et autres fournisseurs d'IA)
• Messages privés accessés entre agents IA
• Modifié ou supprimé des données dans la base de données
• A piraté le compte d'un utilisateur
• Engendrez des factures massives en utilisant des clés API volées

Le rebond ? Le fondateur a admis qu'il avait « complètement vibe-codé » l'ensemble de la plateforme. Aucune revue de code. Aucun audit de sécurité. Juste des invites à une IA et copier-coller les résultats.

Pourquoi cela continue-t-il de se produire ?

Voici ce qui est frustrant dans cette histoire : ce n'est pas unique.

Rappelez-vous quand DeepSeek a exposé ses clés API ? Ou Base44 ? Le schéma se répète parce que la philosophie du vibe coding décourage activement les pratiques qui empêchent ces violations.

La philosophie fondamentale du vibe coding est : allez vite, concentrez-vous sur les résultats, ne vous souciez pas des détails. C'est séduisant parce que — honnêtement — cela fonctionne pour construire des prototypes. Vous pouvez créer une application fonctionnelle en quelques heures.

Mais les applications de production vivent dans un monde différent. Elles gèrent de vraies données utilisateur, de vrais paiements, de vraies menaces de sécurité. La même mentalité qui vous aide à livrer un prototype en un week-end fera pirater votre application de production dès le premier jour.

J'ai parlé à un chercheur en sécurité spécialisé dans le code généré par l'IA. Voici ce qui le préoccupe :

• Incompréhension de ce qui se passe : Lorsque vous demandez à une IA de « construire un système de connexion », vous obtenez du code qui ressemble à un système de connexion mais qui peut comporter des défauts subtils que seul un expert remarquerait
• Faire confiance à l'IA : Les utilisateurs supposent que le code généré par l'IA est sécurisé parce que... c'est de l'IA ? Cette supposition est complètement fausse
• Fondamentaux manquants : Les développeurs de Vibe codent ignorent souvent ce qu'ils ne savent pas sur la sécurité

Le problème des 45 %

Laissez-moi vous donner un chiffre qui devrait vous empêcher de dormir : 45 %.

C'est le pourcentage de code généré par l'IA qui contient des vulnérabilités de sécurité, selon la recherche de Veracode sur la sécurité des logiciels générés par l'IA^[1].

Ce n'est pas une question de mauvais modèles d'IA ou de développeurs incompétents. C'est la nature fondamentale de la génération de code. Les modèles d'IA sont entraînés sur du code existant — qui inclut du code non sécurisé. Ils reproduisent les modèles qu'ils ont vus, y compris les vulnérables.

Les vulnérabilités courantes dans le code généré par l'IA incluent :

La violation de Moltbook était en réalité deux problèmes : une clé API codée en dur (secrets codés en dur) ET une RLS manquante (configuration insecure). L'un ou l'autre seul aurait été mauvais. Ensemble, ils ont créé une catastrophe.

Ce que personne ne vous dit sur le vibe coding

Soyons honnêtes avec vous. J'ai beaucoup codé avec le vibe coding. Cela a vraiment changé ma façon de construire. Mais j'ai aussi appris des leçons difficiles à mes dépens.

Vous devez quand même comprendre la sécurité

Voici une vérité inconfortable : vous ne pouvez pas utiliser d'outils IA pour construire des applications sécurisées si vous ne comprenez pas la sécurité vous-même. L'IA ne connaît pas votre modèle de menace. Elle ne sait pas quels actifs vous protégez. Elle génère simplement du code qui semble raisonnable.

Vous n'avez pas besoin de devenir un expert en sécurité. Mais vous devez comprendre :

• Ne mettez jamais de secrets dans le code côté client
• Toujours activer la sécurité au niveau des lignes sur les bases de données
• Utilisez des variables d'environnement pour la configuration sensible
• Implémenter une validation des entrées correcte
• Exécutez des analyses de sécurité sur le code généré

Prototyper vite, puis ingénier

Mon flux de travail actuel :

• Codez le prototype en Vibe — Faites fonctionner quelque chose, validez l'idée avec de vrais utilisateurs
• Identifier l'adéquation produit-marché — Avant d'investir quoi que ce soit
• Refactoriser pour la production — C'est là que vous ingéniez réellement la sécurité, les performances et la maintenabilité

L'erreur consiste à expédier des prototypes codés par vibes directement en production sans l'étape de refactorisation. Vous ne gagnez pas de temps — vous accumulez de la dette technique qui vous coûtera plus tard.

Utilisez le bon outil pour le travail

Cela peut être controversé, mais je ne pense pas que le vibe coding soit approprié pour :

• Applications traitant des données sensibles (santé, finance)
• Systèmes qui traitent les paiements
• Tout ce qui comporte des exigences de conformité réglementaire
• Applications où les défaillances de sécurité pourraient causer des dommages réels

Pour les outils internes, les MVP et les prototypes ? Allez-y. Pour les systèmes de production gérant des données utilisateur réelles ? Concevez-le correctement.

Comment vous protéger

Si vous faites du vibe coding de toute façon (et honnêtement, vous devriez — c'est incroyablement puissant), voici comment éviter de devenir le prochain titre :

Pour votre Supabase/Backend

javascript
// WRONG - Never do this
const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE')
// Your service_role key is also exposed here!

// CORRECT - Use environment variables, server-side only
const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_ANON_KEY
)

Liste de contrôle de sécurité essentielle

• [ ] Activer la sécurité au niveau des lignes sur TOUTES les tables de base de données
• [ ] Stocker les clés API dans des variables d'environnement, jamais dans le code
• [ ] Exécutez un scan de sécurité sur tout le code généré (Snyk, CodeQL ou GitHub Advanced Security)
• [ ] Ne jamais exposer les clés service_role au client
• [ ] Mettre en œuvre une validation des entrées appropriée sur toutes les entrées utilisateur
• [ ] Configurer la limitation de débit pour prévenir les abus
• [ ] Réalisez un test de pénétration avant de lancer quoi que ce soit avec de vrais utilisateurs

Outils utiles

Ce que cela signifie pour l'industrie

Je suis sincèrement inquiet pour où nous allons.

Nous sommes au milieu d'un changement massif dans la façon dont les logiciels sont créés. Les fondateurs non techniques peuvent désormais créer des applications sophistiquées. La barrière à l'entrée s'est effondrée. C'est véritablement passionnant.

Mais nous créons aussi une génération d'applications sans personne qui surveille le magasin.

Voici ce qui doit se passer selon moi :

• Les outils de codage IA ont besoin de meilleures valeurs par défaut de sécurité — Arrêtez de générer du code avec des vulnérabilités intégrées
• Les communautés doivent en parler davantage — Chaque article de blog sur la programmation vibe devrait mentionner la sécurité
• Nous avons besoin de meilleurs outils — L'analyse de sécurité automatisée devrait être intégrée à chaque flux de travail de codage IA
• Les fondateurs doivent assumer la responsabilité — Vous ne pouvez pas blâmer l'IA quand quelque chose tourne mal

L'avenir du développement logiciel ne consiste pas à choisir entre la vitesse de l'IA et la sécurité. C'est apprendre à utiliser les deux ensemble.

Foire aux questions

Le mot de la fin

Moltbook n'est pas une anomalie. C'est un aperçu de ce qui arrive.

À mesure que de plus en plus de fondateurs déploient des applications codées par IA sans comprendre les fondamentaux de la sécurité, nous verrons plus de violations. Plus de clés API exposées. Plus de bases de données accessibles. Plus de victimes.

Ce n'est pas un argument contre le vibe coding. C'est un argument pour être honnête sur ses limites.

Déployez vite. Testez les idées. Allez vite. Mais avant de mettre les données réelles des utilisateurs en danger, ralentissez et faites le travail de sécurité. Vos utilisateurs vous font confiance avec leurs informations. Cette confiance ne doit pas être sacrifiée au nom du rythme.

Articles connexes

• Qu'est-ce que le vibe coding ? Le guide complet 2026
• Cursor vs Windsurf pour le Vibe Coding : Lequel gagne en 2026 ?
• Comment créer une application IA en 7 jours (étape par étape)
• Comment obtenir 100 testeurs bêta rapidement

Prêt à lancer votre application en toute sécurité ? Répertoriez votre application sur GetFree — un répertoire curaté où les développeurs partagent des codes promo et l'accès bêta avec des milliers de testeurs ciblés.

Sources

Initialement publié sur Blog GetFree.APP — Dernière mise à jour : 17 février 2026