Sécuriser une app Lovable : la checklist avant de lancer

Lovable, c'est génial pour sortir une app en un week-end. Le souci arrive juste après le déploiement : personne ne t'a dit ce qui reste ouvert derrière. Sur les apps Lovable que je passe au scanner, c'est presque toujours la même histoire. Environ 70 % ont le RLS Supabase désactivé, et une bonne partie sert des fichiers source ou une clé visibles dans le navigateur.

Ce n'est pas de ta faute. Lovable optimise pour que ça marche, pas pour que ce soit fermé. Cette page, c'est la checklist que je passe sur chaque app Lovable, dans l'ordre : ce que l'outil ferme tout seul, ce qu'il te laisse sur les bras, et comment vérifier chaque point en quelques minutes avant de lancer.

Ce que Lovable fait bien, et ce qu'il te laisse gérer

Lovable te sert du solide sur l'infra. HTTPS activé par défaut, une app React qui tourne, Supabase branché sans que tu écrives une ligne de SQL. Pour aller vite, c'est imbattable.

Le trou est ailleurs. L'IA qui code ton app crée tes tables, colle ta clé publique et passe à la suite. Elle n'active pas toujours le verrou de ta base. Elle ne coupe pas les fichiers de debug en production. Elle ne pose pas les en-têtes de sécurité. Tout ça, ce sont des gestes que personne ne fait à ta place quand tu vibe-codes. Toi tu vois une app qui fonctionne. Un curieux, lui, ouvre les outils de développeur et voit ce que tu exposes vraiment.

La faille n°1 : ta base Supabase lisible sans mot de passe

C'est de loin ce que je trouve le plus souvent sur Lovable. Ton app parle à Supabase avec une clé publique, la clé anon. Cette clé est faite pour être dans ton code, c'est normal, elle ne verrouille rien toute seule. Le vrai verrou, c'est le RLS (Row Level Security), qui décide qui a le droit de lire quelle ligne.

Tant que le RLS est désactivé sur une table, la clé publique suffit à tout lire : emails, commandes, messages. La clé sur la porte n'est pas le problème. Le problème, c'est que la porte derrière est grande ouverte. Environ 70 % des apps Lovable analysées avaient le RLS désactivé, et 1 sur 10 exposait carrément des tables en public. J'ai détaillé ce combo dans Lovable et Supabase : la faille RLS que tu dois fermer, et le fond de la faille dans RLS désactivé : pourquoi ta base est lisible.

Un point de méthode, parce que c'est notre façon de travailler : Colmate ne va jamais interroger ta base pour te prouver qu'elle est ouverte. Il repère que ton app utilise Supabase avec une clé publique exposée côté client, le profil exact de cette faille, et te signale l'exposition probable à vérifier. La confirmation, c'est toi qui la fais, en deux minutes.

Les clés secrètes que Lovable peut laisser dans le navigateur

Il y a deux familles de clés. Les publiques, faites pour être vues (la clé anon de Supabase, une clé Stripe pk). Et les secrètes, qui ne doivent jamais finir côté navigateur : la service_role de Supabase, une clé Stripe sk_live, une clé OpenAI.

Lovable te propose de ranger les secrets au bon endroit, dans les Edge Functions Supabase, côté serveur. Mais si tu demandes une fonctionnalité et que l'IA colle la clé directement dans le code du front pour que ça marche tout de suite, elle se retrouve dans le JavaScript téléchargé par chaque visiteur. Une service_role exposée, c'est la clé de ta maison posée sur le paillasson avec un panneau bienvenue : elle ignore le RLS, elle lit et écrit tout.

Comment vérifier : ouvre ton app Lovable, clic droit, Inspecter, onglet Sources, et cherche service_role, sk_live, sk-. Ces mots ne doivent jamais apparaître. S'ils sont là, c'est exposé, et il faut régénérer la clé côté Supabase ou Stripe, puis la déplacer côté serveur.

Ton code source Lovable, parfois servi en clair

Lovable construit ton app avec Vite. En production, beaucoup d'apps servent encore leurs source maps, ces fichiers .map qui reconstruisent ton code d'origine à partir du JavaScript compilé. Pratique pour déboguer, catastrophique en public.

Un curieux télécharge le .map et lit la logique de ton app comme si tu lui avais donné ton dépôt. Il repère tes vraies failles plus vite, et parfois une clé oubliée dans un commentaire. C'est ce que je retrouve le plus après le RLS : sur une dizaine d'apps scannées un matin au hasard des pubs, 5 servaient leur code de cette façon.

Comment vérifier : dans l'onglet Sources des DevTools, si tu vois ton arborescence de fichiers d'origine, avec des .tsx lisibles, les source maps partent en prod. À couper dans la config de build.

Les en-têtes de sécurité, que Lovable ne pose pas pour toi

Les en-têtes (CSP, HSTS, X-Frame-Options) sont les serrures secondaires de ton app. Seuls, ils ne fuient pas tes données. Leur absence ouvre la porte au détournement de session, à l'injection de code, à l'affichage de ton app dans une fausse page. La plupart des apps Lovable n'en posent aucun, parce que personne ne leur a dit de le faire.

C'est le niveau le moins grave de la liste, mais il compte. Le RGPD parle de « mesures techniques appropriées » (article 32), et des en-têtes absents, c'est le signe qu'une app est partie en prod sans que personne n'ait vérifié les fondamentaux. Certains en-têtes dépendent de ton hébergement et du domaine que tu as branché, pas du code Lovable lui-même.

Est-ce que Lovable sécurise mon app tout seul ?

Non, pas entièrement, et c'est la question qui coince tout le monde. Lovable gère l'infra, le HTTPS, le déploiement. Il ne garantit pas que ta base est verrouillée, que tes secrets sont côté serveur, ou que tes fichiers de debug sont coupés. Ces trois points restent à ta charge, et ce sont exactement ceux qui exposent des données.

C'est vrai pour Lovable comme pour les autres builders. Le défaut est le même partout : l'app tourne avant que les portes aient été fermées. Si tu es passé par un autre outil, la trame vaut aussi pour Bolt, v0 et Replit, avec chacun sa manière de laisser fuir.

Ta checklist Lovable avant de lancer

Point à vérifier	Lovable le fait ?	Ce que tu dois vérifier
HTTPS	Oui, par défaut	Rien
RLS activé sur Supabase	Non, souvent oublié	Chaque table qui contient des données perso
Clés secrètes côté serveur	Non garanti	Aucun service_role / sk_live dans le navigateur
Source maps coupées en prod	Non par défaut	Pas de code d'origine lisible dans Sources
En-têtes de sécurité	Non	CSP et HSTS présents
Pages légales	Non	Mentions légales et confidentialité dans le footer

La version rapide : tout voir d'un coup

Passer ces points à la main, c'est faisable, mais il faut savoir où creuser et lire ce que tu vois. Colmate fait la revue en trente secondes depuis l'URL de ton app Lovable. Tu colles le lien, tu obtiens la liste de ce qui est exposé (clés, source maps, en-têtes, pages légales), classé par gravité, avec un fichier de correction prêt à coller dans ton assistant IA. Pour la base, il ne teste rien : il repère la présence de Supabase avec une clé publique exposée et te signale l'exposition probable à vérifier.

En lecture seule, sans accéder à ton code, sans jamais toucher à tes données. Je n'ai pas besoin de ton dépôt GitHub, juste de l'URL publique, celle que n'importe quel visiteur voit déjà. Scanne ton app Lovable maintenant, c'est gratuit.

FAQ

Lovable active-t-il le RLS Supabase automatiquement ?

Pas de façon fiable. Lovable crée tes tables et branche la clé publique, mais l'activation du RLS et l'écriture des bonnes règles ne se font pas systématiquement. C'est pour ça qu'environ 70 % des apps Lovable que je scanne ont le RLS désactivé. À vérifier table par table avant de lancer, en suivant la méthode DevTools en deux minutes.

Ma clé Supabase est visible dans mon app Lovable, c'est grave ?

Ça dépend de la clé. La clé anon est publique par design, elle est censée être dans ton app, la voir est normal. Ce qui est grave, c'est de trouver une clé service_role ou une sk_live Stripe dans le navigateur : celles-là sont secrètes et donnent un accès complet. La vraie question n'est pas « ma clé est-elle visible », c'est « ma base est-elle verrouillée derrière ».

Faut-il être développeur pour sécuriser une app Lovable ?

Non. La plupart des vérifications se font dans les outils de développeur de ton navigateur (clic droit, Inspecter), sans écrire de code. Pour corriger le RLS, Lovable te laisse écrire du SQL directement, et les policies prêtes à coller sont ici. Si tu veux zapper la partie technique, un scan te signale directement les points exposés.

Le réflexe avant de lancer

Tu ne mettrais pas ton app en ligne sans regarder à quoi elle ressemble. Fais pareil pour ce qu'elle expose. Avant de la partager, avant de la lancer sur les réseaux, prends quelques minutes pour vérifier que tu n'as pas laissé la clé sur la porte. La checklist complète avant déploiement reprend les six points pour tous les outils, et ce que ton app vibe-codée expose vraiment explique chaque faille en détail.

Lance un scan gratuit de ton app Lovable. Si quelque chose fuit, tu le sauras, et tu repartiras avec de quoi le colmater.