J'ai scanné 50 apps Lovable — Voici ce que j'ai découvert

Lovable est l'une des plateformes de codage IA les plus populaires, avec des milliers d'applications mises en ligne chaque semaine. Mais quel est leur niveau de sécurité ?

Nous avons décidé de le vérifier. Nous avons scanné 50 vraies applications Lovable actuellement en ligne sur internet à l'aide de l'analyseur de sécurité en 8 points de ScanVibe. Les résultats sont... préoccupants.

Méthodologie

Nous avons collecté 50 applications accessibles publiquement, construites avec Lovable, depuis :

• La vitrine et la galerie communautaire de Lovable
• Des publications Twitter/X taguées #builtwithlovable
• Des lancements Product Hunt mentionnant Lovable
• Des posts Reddit sur r/lovable et r/webdev

Chaque application a été scannée avec la suite de sécurité complète de ScanVibe, qui vérifie : SSL/TLS, les en-têtes de sécurité, les secrets exposés, les bibliothèques JavaScript, les fichiers exposés, la configuration Supabase, la configuration Firebase et les endpoints d'authentification.

Nous avons uniquement scanné des URL accessibles publiquement. Aucun identifiant de connexion n'a été utilisé et aucune donnée n'a été modifiée.

Les résultats en un coup d'œil

Les 5 vulnérabilités les plus courantes

1. Row Level Security Supabase manquant — 78% des apps

C'est le problème de sécurité numéro un de l'écosystème Lovable. 39 applications sur 50 avaient au moins une table Supabase sans RLS activé.

Sans RLS, toute personne connaissant votre URL Supabase et votre clé anon (qui se trouve dans le code côté client par conception) peut lire, modifier ou supprimer toutes les données de ces tables. Données utilisateurs, informations de paiement, messages privés — tout est exposé.

2. En-têtes de sécurité manquants — 74% des apps

37 applications ne disposaient pas d'en-têtes de sécurité essentiels comme Content-Security-Policy, X-Frame-Options et Strict-Transport-Security.

Sans ces en-têtes, les applications sont vulnérables au cross-site scripting (XSS), au clickjacking et aux attaques de type man-in-the-middle.

3. Clés API exposées dans le code source — 62% des apps

31 applications avaient au moins une clé API visible dans le bundle JavaScript côté client. Si les clés anon Supabase sont conçues pour être publiques (quand le RLS est activé), nous avons également trouvé :

Ces clés peuvent être extraites en quelques secondes avec les DevTools du navigateur.

4. Bibliothèques JavaScript obsolètes — 56% des apps

28 applications utilisaient des packages JavaScript présentant des vulnérabilités connues (CVE). Les plus courants :

• Des versions obsolètes de next avec des vulnérabilités XSS connues
• Des versions vulnérables de postcss et webpack
• Des packages non maintenus sans correctifs de sécurité

5. Configuration d'authentification faible — 44% des apps

22 applications dotées d'une authentification présentaient des problèmes :

• Pas de rate limiting sur les endpoints de connexion (18 apps)
• Pas de vérification d'email requise (15 apps)
• Exigences de mot de passe trop permissives (12 apps)
• Protection CSRF manquante (8 apps)

Distribution des scores

Voici comment les 50 applications se répartissent sur notre échelle de A à F :

Les 3 applications qui ont fait les choses correctement

Trois applications se sont distinguées par de bonnes pratiques de sécurité. Qu'avaient-elles en commun ?

La conclusion : les applications vibe-codées peuvent être sécurisées, mais cela nécessite un travail de sécurité intentionnel après la génération.

Ce que cela signifie pour les utilisateurs de Lovable

Si vous avez construit une application avec Lovable, il y a de fortes chances qu'elle ait des problèmes de sécurité. Voici quoi faire :

Actions immédiates (5 minutes)

1. Scannez votre app avec ScanVibe — c'est gratuit et ça prend 30 secondes
2. Vérifiez votre note de sécurité et consultez les résultats
3. Si vous voyez « Missing RLS » — c'est votre priorité numéro 1

Corrections prioritaires (30 minutes)

1. Activez le RLS sur toutes les tables Supabase — allez dans votre dashboard Supabase, naviguez vers chaque table et activez le RLS
2. Ajoutez les en-têtes de sécurité — créez un vercel.json avec les en-têtes de sécurité (voir nos instructions de correction)
3. Déplacez les clés secrètes dans les variables d'environnement — ne mettez jamais de clés secrètes dans le code côté client

Protection continue

1. Mettez en place des scans de sécurité hebdomadaires
2. Relancez un scan après chaque mise à jour majeure
3. Vérifiez le code généré par l'IA pour les bonnes pratiques de sécurité avant de déployer

Un mot pour l'équipe Lovable

Soyons clairs : Lovable est un produit incroyable. Il démocratise le développement logiciel et permet à des personnes de créer des applications qui étaient auparavant impossibles sans une équipe de développement.

Mais un grand pouvoir implique de grandes responsabilités. Nous aimerions voir :

• Le RLS activé par défaut sur les nouvelles tables Supabase
• Les en-têtes de sécurité inclus dans les configurations de déploiement par défaut
• Une checklist de sécurité dans le processus de déploiement
• Une intégration avec des outils de scan de sécurité (comme ScanVibe) avant la mise en ligne

Nous contactons l'équipe Lovable pour discuter de la manière dont nous pouvons aider leurs utilisateurs à construire des applications plus sécurisées.

Scannez votre application Lovable maintenant

Ne faites pas partie des 84%. Scannez votre app gratuitement avec ScanVibe et découvrez votre note de sécurité en 30 secondes.

Votre IA l'a construite. Nous vérifions si c'est sécurisé.

Note méthodologique : cette étude a été réalisée en mars 2026. Toutes les applications étaient accessibles publiquement au moment du scan. Nous n'avons tenté d'exploiter aucune vulnérabilité. Les applications ont été sélectionnées en fonction de leur disponibilité publique, et non pour cibler des développeurs spécifiques. Les résultats individuels des scans n'ont pas été publiés afin de protéger les propriétaires des applications.