Sécurité et visibilité pour ton app Lovable

« Sécurité Lovable », ce sont deux choses qu'il vaut mieux séparer. La première, c'est le projet Lovable lui-même : ce que tu colles dans le chat, où il stocke les secrets, qui peut voir ton projet et où l'appli finit déployée. La seconde, c'est le code que Lovable génère, une SPA React sur Supabase qui embarque toujours les mêmes cinq ou six failles. Ce guide couvre les deux, avec un bloc d'instructions pour la section Knowledge de ton projet, un prompt de revue avant de publier et la façon de vérifier le résultat de l'extérieur.

Partie 1 : protéger ton projet Lovable

Ce que tu colles dans le chat y reste

Le chat du projet, c'est l'historique de ton appli : chaque prompt, chaque clé que tu as collée « pour que ça marche » et chaque réponse. Si une clé secrète entre par le chat, le modèle a tendance à l'écrire directement dans le code du frontend, et de là elle voyage dans le bundle vers tous les visiteurs. La règle est simple : les clés n'entrent jamais par le chat. Quand Lovable te demande un secret pour connecter un service, utilise la boîte de secrets qu'il te propose ; ça le stocke comme variable des Edge Functions Supabase, côté serveur, et le code généré le lit avec Deno.env.get.

Secrets : serveur oui, navigateur non

Lovable sait faire deux choses avec une intégration : l'appeler depuis le navigateur ou depuis une Edge Function. La première est correcte pour les clés publiques (l'anon de Supabase, la publishable de Stripe, l'ID d'un projet). La seconde est la seule option pour les clés secrètes (OpenAI, Resend, la secret de Stripe, la service_role). Si tu demandes une fonctionnalité et que le résultat appelle le service depuis un composant React avec la clé dedans, demande-lui explicitement de la déplacer dans une Edge Function. Plus dans les secrets que ton appli laisse fuiter dans le navigateur.

Visibilité du projet et du code

Un projet public sur Lovable expose le code et l'historique des prompts à quiconque a le lien, y compris toute clé que tu as un jour collée. Vérifie la visibilité dans les réglages du projet et, si tu as activé la synchronisation GitHub, que le dépôt soit privé. Si une clé a été dans un projet ou un dépôt public, considère-la comme compromise et fais-la tourner.

Où vit l'appli publiée

Lovable publie sur un sous-domaine .lovable.app ou sur ton propre domaine. Cet hébergement ne te laisse pas configurer d'en-têtes de sécurité ni de redirections personnalisées. Pour beaucoup d'applis, ça suffit ; si tu as besoin de Content-Security-Policy, de HSTS ou de règles de cache, exporte vers GitHub et déploie sur Vercel ou Netlify avec leur fichier de configuration. Garde aussi en tête que l'URL de preview de chaque version est accessible à qui l'a.

Supabase est à toi, pas à Lovable

Quand tu connectes Supabase (ou que tu utilises le backend géré de Lovable, qui est Supabase en dessous), Lovable crée des tables, des policies et des fonctions pour toi. Mais RLS, buckets et réglages Auth restent ta responsabilité. Lovable a ajouté une revue de sécurité avant publication après la CVE-2025-48757 ; prends-la comme un premier filtre, pas comme une garantie, et parcours le guide de sécurité pour Supabase, qui contient trois requêtes SQL pour auditer le projet en une minute.

Partie 2 : les failles que Lovable met dans ton code

• Des tables sans RLS ou avec des policies using (true). L'origine de la CVE et la faille la plus grave. N'importe qui avec la clé anon lit et écrit tes données.
• Des vérifications de permissions seulement dans le frontend. Une route /admin qui se contente de cacher le bouton si l'utilisateur n'est pas admin. Le serveur (RLS ou l'Edge Function) doit vérifier aussi, parce que l'API peut être appelée sans passer par l'interface.
• Des Edge Functions sans authentification ni limite. Le template répond à n'importe qui, avec Access-Control-Allow-Origin: *, et s'il appelle OpenAI ou envoie des e-mails, n'importe qui peut dépenser ton quota. Exige le JWT de l'utilisateur, restreins l'origine et plafonne les requêtes par utilisateur.
• Des buckets publics pour les fichiers des utilisateurs. Lovable crée le bucket en public pour que les images « s'affichent ». Pour les documents privés, bucket privé et URL signées.
• Invisible pour l'IA et les moteurs de recherche. L'appli est une SPA Vite : le HTML arrive vide et les bots de ChatGPT ou Perplexity ne voient rien. Si la landing et le blog comptent, sépare-les de l'appli. Détail dans pourquoi les applis construites avec l'IA sont invisibles pour l'IA.
• Ni en-têtes de sécurité ni métadonnées. Pas de CSP, pas de HSTS, pas de X-Frame-Options, et le titre est celui du template. Le premier point exige de déployer hors de lovable.app ; le second se règle avec un prompt.
• Une validation seulement dans le formulaire. Le champ a un maxLength mais l'Edge Function ou la table acceptent ce qui arrive. Valide aussi côté serveur et dans les contraintes de la base.

Un bloc pour la section Knowledge de ton projet

Dans les réglages du projet, Lovable a une section de connaissances que le modèle lit à chaque requête. Colle ceci pour que les règles s'appliquent dès le premier prompt :

Règles de sécurité de ce projet :
- Toute nouvelle table a le RLS activé et une policy explicite par opération. N'utilise jamais using (true) ni with check (true) sauf sur des tables de contenu public en lecture seule, et préviens-moi quand tu le fais.
- Ne mets jamais de clés secrètes dans le code du frontend. Les intégrations avec des clés secrètes vont dans une Edge Function qui lit le secret avec Deno.env.get.
- Toute Edge Function vérifie le JWT de l'utilisateur sauf indication contraire de ma part, restreint Access-Control-Allow-Origin à notre domaine et valide l'entrée.
- Les permissions d'administrateur sont vérifiées dans le RLS ou sur le serveur, jamais seulement dans le frontend.
- Les fichiers envoyés par les utilisateurs vont dans des buckets privés avec des policies et des URL signées.
- Les colonnes role, is_admin, plan et credits ne sont pas modifiables par l'utilisateur.
- Mets un vrai titre, une vraie meta description et de vraies balises Open Graph dans index.html.

Un prompt de revue avant de publier

Passe en revue la sécurité de ce projet et ne change rien pour l'instant. Réponds avec une liste :
1. Tables sans RLS et policies avec using (true) ou with check (true).
2. Clés ou jetons présents dans le code du frontend, avec le fichier et la ligne.
3. Edge Functions qui ne vérifient pas le JWT, qui répondent avec Access-Control-Allow-Origin: * ou qui ne valident pas l'entrée.
4. Routes ou actions d'administrateur protégées seulement dans le frontend.
5. Buckets publics contenant des fichiers d'utilisateurs.
6. Colonnes de privilège qu'un utilisateur peut modifier.
7. Métadonnées de index.html encore celles du template.
Pour chaque point, propose le changement exact et attends ma confirmation.

Vérifie le résultat de l'extérieur

Ouvre ton appli publiée dans une fenêtre de navigation privée, clic droit, « Afficher le code source », et cherche service_role, sk_live, sk- et Bearer dans les fichiers JavaScript qu'elle charge. Ensuite, sonde l'API Supabase sans session :

curl -s "https://TON_PROJET.supabase.co/rest/v1/profiles?select=*" -H "apikey: TA_CLE_ANON" -H "Authorization: Bearer TA_CLE_ANON"

Si ça renvoie des lignes, cette table est ouverte. Scanaris fait ça et une quarantaine d'autres vérifications en 30 secondes : il détecte que l'appli est faite avec Lovable, sonde les tables Supabase sans session, cherche des secrets dans le bundle, contrôle en-têtes, cookies, CORS et fichiers exposés, et vérifie si ton contenu est lisible sans JavaScript. Pour chaque échec, il te donne un fix prompt à coller dans le chat Lovable avec le changement exact, et il peut rescanner chaque jour, parce qu'une régénération de code peut ramener une faille que tu avais déjà corrigée.

Questions fréquentes

Lovable a-t-il déjà réglé le problème du RLS ?

Lovable a ajouté une revue de sécurité avant publication et amélioré les templates, mais le modèle génère encore des policies ouvertes quand une requête échoue. Le RLS reste ta responsabilité : utilise les requêtes du guide Supabase.

Puis-je mettre des en-têtes de sécurité sur une appli hébergée sur lovable.app ?

Pas depuis Lovable. Si tu en as besoin, synchronise avec GitHub et déploie sur Vercel ou Netlify, où ils se configurent avec un fichier. L'appli continue de s'éditer dans Lovable.

Que faire si j'ai collé une clé secrète dans le chat ?

Fais-la tourner chez le service d'origine même si elle n'est plus dans le code : l'historique du chat et les bundles précédents la conservent. Ensuite, ajoute-la par la boîte de secrets et demande au modèle de déplacer l'intégration dans une Edge Function.