Scannez votre application Lovable avant la fuite.
Lovable livre vite des applications qui fonctionnent, et livre avec elles un jeu prévisible de failles de sécurité. VibeZero lit votre dépôt sur cinq couches, vous dit si l'application peut être lancée sans risque, et revérifie chaque correctif par un nouveau scan.
Les 3 premiers scans sont gratuits, sans carte. Vous voyez le score d'aptitude au lancement avant de payer.
Ce qui tourne mal dans les applications Lovable
Des tables Supabase avec le Row Level Security désactivé
Quand Lovable crée une table, il n'active pas le RLS et n'écrit pas de règle, si bien que tout utilisateur authentifié lit et écrit chaque ligne appartenant à tous les autres. C'est le constat le plus fréquent dans les applications Lovable. Une mauvaise configuration RLS divulguée début 2025 a exposé des e-mails, des clés d'API et des données de paiement sur plus de 170 projets Lovable déployés.
Des clés service-role embarquées dans le navigateur
Le code généré appelle des API tierces directement depuis le client au lieu de passer par un backend, si bien que le secret finit dans le bundle JavaScript, où n'importe qui le lit depuis les DevTools. Les robots collecteurs d'identifiants trouvent une clé dans un bundle public quelques heures après le déploiement.
Des routes qui authentifient mais n'autorisent jamais
Lovable ajoute une authentification de manière fiable. Il vérifie beaucoup moins fiablement que l'utilisateur connecté a le droit de toucher l'enregistrement précis qu'il a demandé, ce qui transforme n'importe quel compte valide en lecture de la table entière.
Des dépendances figées à ce qui était courant lors de la génération
Le lockfile se fige au moment où l'application a été générée et rien ne le met à jour ensuite, si bien que les CVE connues s'accumulent en silence pendant que l'application continue de fonctionner parfaitement.
Le correctif est généralement une Edge Function, pas une réécriture
La plupart des constats Lovable se ramènent à quelques causes racines : activer le RLS et écrire la règle, déplacer l'appel tiers dans une Supabase Edge Function qui détient le secret pour que le navigateur ne voie jamais que la clé anon, et ajouter le contrôle de propriété que la route générée a sauté. VibeZero écrit chacune de ces actions comme une tâche de correction, fichiers concernés et critères d'acceptation joints, prête pour l'agent qui a construit l'application au départ.
La plupart des scanners de vibe coding se contentent de votre URL.
Sonder une application déployée depuis l'extérieur trouve ce qui se trouvait accessible à cette minute-là. Cela ne permet pas de lire la règle que vous n'avez jamais écrite, la clé posée dans votre historique git, ni la CVE trois niveaux plus bas dans votre lockfile. VibeZero se connecte au dépôt, analyse les cinq couches, puis note la livraison.
- Code
OpenGrep sur chaque langage détecté, plus Bandit, gosec et ESLint-security là où ils s'appliquent.
- Dépendances
OSV-Scanner et Grype sur vos lockfiles, pour qu'une CVE transitive ne puisse pas se cacher.
- Secrets
Gitleaks et TruffleHog sur l'arbre de travail et sur l'historique git derrière.
- Configuration
Les scanners de mauvaise configuration de Trivy sur votre infra, vos règles de base de données et vos réglages de déploiement.
- Application en ligne
Des vérifications en direct sur votre URL déployée, une fois que vous avez prouvé qu'elle est à vous.