Lovable est-il sûr ? Les 7 failles à vérifier avant de lancer votre app

Lovable est-il sûr ?

Lovable convient aussi bien aux prototypes qu’aux apps en production, à condition de relire avant le lancement le code généré, les règles d’accès de Supabase (les policies), les secrets, l’authentification et la validation des saisies. La sécurité d’une app Lovable dépend de sa configuration : une démo qui marche parfaitement peut quand même exposer des données clients si la Row Level Security manque ou si une clé à privilèges se retrouve dans le navigateur.

Risque 1 : la Row Level Security n’est pas activée

C’est la faille la plus grave des apps Lovable. Quand Lovable crée les tables de votre base Supabase, la Row Level Security (RLS), c’est-à-dire la sécurité au niveau des lignes, peut ne pas être activée, ou être mal configurée. Sans RLS, toute personne qui a l’URL de votre projet Supabase et sa clé anon (toutes deux visibles dans le code de votre frontend, la partie de l’app qui tourne dans le navigateur) peut lire, modifier ou supprimer les données des tables non protégées.

Un consultant avait créé dans Lovable une app de gestion clients pour un grand compte. En démo, tout fonctionnait parfaitement. Mais avant la signature, le client a demandé une revue de sécurité, et l’auditeur a constaté que chaque table était lisible publiquement. Le contrat a failli tomber à l’eau.

Comment vérifier : ouvrez le tableau de bord Supabase, allez dans l’éditeur SQL et lancez :

SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';

Toute table qui contient des données utilisateurs et affiche false dans la colonne rowsecurity est un risque critique.

Comment corriger : activez la RLS sur chaque table et ajoutez des policies qui limitent l’accès en fonction de auth.uid(). La Security View de Lovable peut vous guider, mais vérifiez toujours à la main.

Risque 2 : la clé service role dans le code du frontend

Supabase vous donne deux clés : la clé anon (sans danger côté frontend, elle respecte la RLS) et la clé service role (qui contourne toute la sécurité). Si votre app Lovable utilise par erreur la clé service role dans le code exécuté par le navigateur, toutes les protections que vous avez mises en place sautent.

C’est plus fréquent qu’on ne le croit. Le code généré par l’IA pointe parfois vers la mauvaise variable d’environnement, ou l’on copie la mauvaise clé depuis le tableau de bord Supabase.

Comment vérifier : cherchez la valeur de votre clé service role dans tout le code. Dans Lovable, ouvrez le panneau Secrets et vérifiez quelle clé est utilisée dans les fichiers du frontend, et laquelle dans les Edge Functions.

Comment corriger : la clé service role ne doit apparaître que dans les Edge Functions de Supabase (côté serveur). Côté navigateur, c’est la clé anon qu’on utilise.

Risque 3 : des clés d’API écrites en dur dans le code généré

Quand vous demandez à Lovable de brancher un service externe (Stripe, OpenAI, SendGrid), l’IA écrit parfois les clés d’API directement dans le code source. Lovable repère mieux ce cas qu’avant, mais ça arrive encore.

Comment vérifier : Lovable détecte les clés d’API collées dans le chat et vous prévient. Parcourez quand même les fichiers générés à la recherche de tout ce qui ressemble à une clé (de longues suites de lettres et de chiffres, tout ce qui commence par sk_, pk_ ou api_).

Comment corriger : déplacez toutes les clés dans les Secrets de Lovable, et n’y accédez que depuis des Edge Functions, qui servent d’intermédiaire sécurisé entre votre frontend et les services externes.

Risque 4 : des routes sensibles sans authentification

Lovable sait générer de belles interfaces avec une navigation propre, mais l’IA n’ajoute pas toujours la vérification de connexion sur chaque route qui en a besoin. Vous pouvez avoir une page /dashboard qui fonctionne parfaitement une fois connecté, mais qui affiche aussi les données à un visiteur non connecté.

Comment vérifier : ouvrez votre app dans une fenêtre de navigation privée (donc sans session) et allez directement sur les URL qui devraient exiger une connexion.

Comment corriger : ajoutez sur ces routes une vérification qui exige une session valide et renvoie sinon vers la page de connexion. Dans Lovable, demandez : « Ajoute une vérification de connexion sur toutes les routes protégées. »

Risque 5 : des policies RLS trop permissives

Activer la RLS ne suffit pas si les policies sont trop larges. Un schéma fréquent dans le code généré par l’IA : USING (true). Techniquement, la RLS est activée, mais tout le monde a accès à tout.

Comment vérifier : passez en revue chaque policy RLS dans le tableau de bord Supabase. Repérez celles qui utilisent USING (true) ou WITH CHECK (true).

Comment corriger : remplacez ces policies permissives par des règles limitées à chaque utilisateur : USING (user_id = auth.uid()). Pour les policies d’INSERT, ajoutez WITH CHECK (user_id = auth.uid()).

Risque 6 : aucune validation des données saisies

Le code généré par l’IA accepte souvent les saisies des utilisateurs sans les valider. C’est la porte ouverte aux injections SQL, au cross-site scripting (XSS) et à la corruption des données.

Comment vérifier : regardez les formulaires et les routes d’API de votre app Lovable. Les saisies sont-elles validées avant d’être enregistrées ? Nettoyées avant d’être affichées ?

Comment corriger : validez les saisies côté API (dans les Edge Functions). Utilisez des requêtes paramétrées pour accéder à la base. Nettoyez tout contenu fourni par un utilisateur avant de l’afficher en HTML.

Risque 7 : des messages d’erreur trop bavards

Par défaut, le code généré par l’IA renvoie souvent des messages d’erreur détaillés : structure de la base, chemins de fichiers, traces d’exécution (stack traces). Autant d’indices qui aident un attaquant à comprendre votre système.

Comment vérifier : provoquez des erreurs dans votre app (formulaire mal rempli, URL cassée) et regardez ce que voit l’utilisateur.

Comment corriger : en production, remplacez les messages détaillés par des messages génériques. Gardez le détail dans les journaux côté serveur pour déboguer, mais ne le montrez jamais aux utilisateurs.

Et maintenant

Passez ces 7 risques en revue avant de publier votre app Lovable. Comptez environ 30 minutes : c’est peu, face au genre d’incident de sécurité qui coule un produit.

Si vous voulez une vérification automatique qui repère ces problèmes avant vos utilisateurs, BWorlds analyse votre app à la recherche de ces failles précises et vous remet un rapport clair : validé ou à corriger, point par point.