Application Lovable en production : la checklist sécurité et données

Votre application Lovable a ses premiers vrais utilisateurs. Des gens que vous ne connaissez pas y créent des comptes, y déposent leur adresse email, parfois leur moyen de paiement. C'est une réussite : la plupart des projets ne dépassent jamais le stade de la démo. C'est aussi le moment le plus risqué de la vie du produit, parce qu'entre le premier prompt et aujourd'hui, personne n'a probablement relu ce que l'IA a généré.

Ce risque a été chiffré. En mai 2025, la CVE-2025-48757 a documenté plus de 170 applications Lovable dont la base de données se laissait lire, et parfois modifier, par n'importe quel internaute : listes d'utilisateurs, statuts de paiement, clés d'API. Sans mot de passe, sans outillage sophistiqué. Lovable a corrigé sa génération de code et ajouté un scanner de sécurité, on y reviendra. Le risque de fond, lui, reste entier, parce qu'il ne tient pas à un bug de la plateforme : il tient à des réglages qui vous appartiennent.

D'où cette checklist en 8 points, écrite pour des fondateurs et responsables produit qui ne sont pas développeurs. Chaque point explique le risque, une façon simple de vérifier, et le remède. Elle vaut pour une application Lovable, et pour l'essentiel pour un projet Bolt ou v0 branché sur Supabase : le modèle de données est le même.

Prérequis avant de dérouler la checklist

Pas besoin de savoir coder pour vérifier. Il vous faut :

• l'accès propriétaire à votre projet Lovable et au tableau de bord Supabase associé (ou au panneau Cloud du projet si vous utilisez Lovable Cloud) ;
• l'accès au tableau de bord de votre prestataire de paiement si vous encaissez, Stripe le plus souvent ;
• deux comptes de test dans votre application : un compte « client » et un compte « curieux » ;
• deux à quatre heures, au calme.

Certains remèdes demanderont ensuite un développeur ou une relecture experte. L'état des lieux, lui, est à votre portée.

Votre application Lovable montre sa clé de base de données, et c'est normal

Une application Lovable branchée sur Supabase interroge sa base de données directement depuis le navigateur, avec une clé publique appelée clé anon. Cette clé est visible par n'importe quel visiteur qui ouvre les outils de développement de son navigateur. Ce n'est pas une fuite : c'est le modèle prévu par la documentation Supabase, et il fonctionne bien, à une condition. La seule barrière entre un internaute et vos tables, ce sont les règles Row Level Security (RLS) : des politiques d'accès écrites dans la base, qui filtrent chaque requête ligne par ligne. Une politique se lit comme une phrase : « un utilisateur connecté ne voit que les lignes dont il est propriétaire ».

Le flux complet tient en un schéma :

flowchart TD
    A[Navigateur du visiteur<br/>avec la clé anon, publique par design] --> B[API de la base de données<br/>endpoint public auto-généré]
    B --> C{RLS activée et politiques écrites ?}
    C -->|oui| D[Chaque requête est filtrée :<br/>l'utilisateur ne voit que ses lignes]
    C -->|non, ou politique USING true| E[Toute la table est lisible<br/>et modifiable par n'importe qui]
    D --> F[(Tables Postgres)]
    E --> F

Le chemin du bas est le scénario exact de la CVE-2025-48757. Pas de RLS, ou une politique USING (true) qui autorise tout le monde : la base est ouverte, alors que l'application, elle, semble parfaitement normale.

Depuis septembre 2025, Lovable propose aussi Lovable Cloud, un backend intégré. Il repose sur Supabase : chaque projet Lovable Cloud est un projet Supabase sous le capot. La checklist s'applique donc à l'identique.

CVE-2025-48757 : ce que l'incident a montré

Les projets générés par Lovable jusqu'au 15 avril 2025 (et parfois après) pouvaient être déployés avec des politiques RLS absentes ou insuffisantes. Résultat mesuré par la divulgation de Matt Palmer : des attaquants non authentifiés pouvaient lire et écrire des tables arbitraires, pour un score de sévérité CVSS de 9.3 sur 10. Son scan a recensé 303 points d'entrée vulnérables répartis sur plus de 170 applications : emails, numéros de téléphone, statuts d'abonnement, clés d'API de services tiers.

Lovable a depuis fait évoluer sa génération de code et intégré un scanner de sécurité qui signale notamment les tables sans RLS, avec des vérifications relancées après chaque changement de schéma. C'est un vrai progrès, et il faut le dire. Il faut dire aussi ce que ce scanner ne fait pas : vérifier que vos politiques correspondent à votre métier. On y arrive plus bas.

La checklist sécurité en 8 points avant d'ouvrir votre application Lovable

1. Des règles d'accès (RLS) sur chaque table, testées avec deux comptes

Le point n°1, celui de la CVE. Dans le tableau de bord Supabase, section Tables, chaque table doit indiquer « RLS enabled » et lister au moins une politique. Puis testez en conditions réelles : connectez-vous avec votre compte « curieux » et cherchez à voir les données du compte « client ». Sur une table sensible, une politique USING (true) en lecture est un drapeau rouge. Le remède : activer la RLS partout, écrire des politiques par rôle, et déplacer côté serveur ce qui ne doit jamais transiter par le navigateur. On a détaillé ce cloisonnement sur un cas concret dans notre article sur l'architecture d'une plateforme immobilière off-market.

2. Aucun secret côté navigateur, aucun secret dans l'historique Git

La clé anon peut être publique ; tout le reste, non. Clés Stripe secrètes, clés d'API d'IA, clé Supabase service_role : si l'une d'elles apparaît dans le code envoyé au navigateur ou dans l'historique de votre dépôt GitHub, elle est compromise, même si vous l'effacez ensuite. L'historique Git garde tout. Vérifiez en cherchant « sk_live », « secret » ou « key » dans votre dépôt. Le remède n'est pas de supprimer la ligne : c'est de révoquer la clé chez le fournisseur et d'en générer une nouvelle, stockée côté serveur, dans les secrets des Edge Functions par exemple.

3. Des parcours d'authentification complets, pas seulement l'inscription

L'IA génère très bien le parcours heureux : s'inscrire, se connecter. Elle oublie souvent les bords : vérification de l'adresse email désactivée (n'importe qui peut s'inscrire avec l'email d'un autre), réinitialisation de mot de passe jamais testée, suppression de compte absente alors que le RGPD l'exige. Déroulez les quatre parcours avec un compte jetable : inscription, vérification d'email, mot de passe oublié, suppression de compte. Ce qui coince se corrige en général dans les réglages Supabase Auth et en quelques prompts ciblés.

4. Des paiements décidés par le serveur, pas par le navigateur

Si le montant d'un paiement est calculé dans le navigateur, un utilisateur outillé peut payer le prix qu'il choisit. Si vos webhooks Stripe (les notifications de paiement que Stripe envoie à votre application) ne sont pas vérifiés par signature, n'importe qui peut simuler un paiement réussi. Trois questions à poser, à votre développeur ou à l'IA elle-même : la signature des webhooks est-elle vérifiée ? Les montants sont-ils recalculés côté serveur ? Un même événement reçu deux fois crée-t-il deux commandes (c'est l'idempotence) ? Depuis le dashboard Stripe, on peut rejouer un événement pour tester ce dernier point. On a documenté cette mécanique dans notre guide des marketplaces avec Stripe Connect.

5. Des environnements séparés, et une restauration testée pour de vrai

Tant que l'agent IA et vos clients travaillent sur la même base de données, chaque prompt est une opération en production. L'incident Replit de juillet 2025 l'a illustré : l'agent a supprimé la base de production d'un projet de Jason Lemkin, plus de 2 400 enregistrements, pendant un gel de code explicite, puis a affirmé à tort que la restauration était impossible. Elle a finalement fonctionné, et Replit a déployé dans la foulée la séparation des environnements de développement et de production. Tirez-en les deux conséquences : un environnement de travail distinct de la production, et une sauvegarde restaurée au moins une fois. Tant que vous n'avez jamais essayé une restauration, vous ne savez pas si vos sauvegardes existent vraiment.

6. Savoir quelles données personnelles vous collectez, et où elles partent

Dès le premier utilisateur réel, vous êtes responsable de traitement au sens du RGPD. L'inventaire tient en trois colonnes : ce que vous collectez (emails, noms, données d'usage), où ça part (outil d'analytics, API d'IA qui reçoit le contenu des utilisateurs, service d'emailing), et sur quelle base (consentement, contrat). Les applications générées embarquent souvent un analytics américain par défaut et envoient des données utilisateur à une API d'IA sans que personne l'ait décidé. Le remède : minimiser, documenter dans une politique de confidentialité honnête, et préférer des outils européens ou auto-hébergés quand c'est possible, un Umami auto-hébergé ou un Plausible pour l'analytics par exemple.

7. Des garde-fous de coûts sur tout ce qui est facturé à l'usage

Une fonctionnalité d'IA branchée sur un formulaire public, sans limite de débit, c'est une facture ouverte à tous les visiteurs : chaque appel vous coûte quelques centimes, et rien n'empêche un script d'en déclencher des dizaines de milliers. Vérifiez trois choses : des alertes de facturation chez chaque fournisseur (Supabase, Stripe, fournisseur d'IA), des plafonds de dépense quand ils existent, et une limite de débit par utilisateur ou par adresse IP sur les fonctions qui appellent une API payante. C'est le point le moins spectaculaire de la liste et l'un des plus fréquents dans les mauvaises surprises.

8. Trois parcours critiques re-testés avant chaque publication

Chaque prompt peut modifier des fichiers sans rapport avec votre demande : c'est le fonctionnement normal d'un agent de génération de code. Sans tests, la régression se découvre en production, par un client. Identifiez vos trois parcours vitaux (typiquement : s'inscrire, réaliser l'action cœur du produit, payer) et re-déroulez-les avant chaque publication. La version outillée : des tests automatisés type Playwright exécutés à chaque déploiement. La version minimale, accessible dès aujourd'hui : une checklist manuelle de dix minutes, tenue sans exception.

La même checklist, vue d'ensemble

Un scanner ne répondra jamais à la question : qui a le droit de voir quoi

Le scanner intégré à Lovable détecte des patterns connus : une table sans RLS, une clé qui traîne dans le code. C'est utile, et ça élimine les erreurs les plus grossières. Mais « qui a le droit de voir quoi » n'est pas une signature de vulnérabilité : c'est une décision métier. Un devis doit-il être visible du client, du commercial qui l'a émis, de toute l'équipe ? Une politique RLS qui autorise « tous les utilisateurs connectés » est techniquement correcte et peut être une catastrophe pour votre activité. Aucun scanner ne connaît votre réponse, parce qu'elle n'est écrite nulle part ailleurs que dans votre tête.

L'été 2025 en a fourni la démonstration. Base44, une plateforme de vibe coding rachetée par Wix, mettait en avant des applications privées d'entreprise protégées par SSO. Le 9 juillet 2025, Wiz Research a montré qu'un attaquant pouvait créer un compte vérifié sur ces applications privées avec pour seule information l'app_id, une valeur publique visible dans l'URL, en contournant le SSO. Wix a corrigé en moins de 24 heures et n'a constaté aucune exploitation : la réponse a été rapide et transparente. La leçon reste : même la plateforme qui met la sécurité en avant peut faillir. Votre application a besoin de plusieurs couches de défense, pas d'une confiance totale en une seule.

Les chiffres de fond vont dans le même sens. Le rapport GenAI Code Security de Veracode, publié le 30 juillet 2025 après des tests sur plus de 100 modèles, mesure que le code généré par IA introduit une vulnérabilité du top 10 OWASP dans 45 % des cas, un taux stable quels que soient le modèle et sa date de sortie. Les modèles progressent sur tout, sauf là-dessus.

Si la checklist révèle des trous : reprendre, pas jeter

Des points rouges sur la checklist ne condamnent pas votre application. Dans les relectures d'applications générées qu'on pratique, la remédiation se compte en jours : ordres de grandeur observés, deux à quatre jours pour un cloisonnement RLS complet sur une application typique, quelques heures pour sortir les secrets du code client, une journée pour fiabiliser les webhooks. Le produit, l'interface, le parcours utilisateur que vos clients aiment : tout cela reste. Reprendre un existant imparfait coûte souvent moins cher qu'on l'imagine ; on l'a vérifié sur l'application de Jean-Charles de Castelbajac pour le Centre Pompidou, dont le développement initial posait des problèmes structurels et qu'on a recodée sur des technologies standard pour un budget inférieur aux simples évolutions initialement prévues. Et dans tous les cas, une reprise coûte infiniment moins qu'une fuite de données.

Questions fréquentes

Q : La clé Supabase visible dans mon navigateur est-elle une faille ?

A : Non. La clé anon est publique par design : le modèle Supabase prévoit que le navigateur interroge la base directement, et confie toute la protection aux règles Row Level Security. Le vrai sujet d'audit, ce sont les politiques RLS de chaque table, pas la visibilité de la clé.

Q : Le scanner de sécurité de Lovable suffit-il avant d'ouvrir ?

A : Il est nécessaire, pas suffisant. Il détecte des patterns connus (table sans RLS, secret exposé) mais ne peut pas valider vos règles métier d'accès aux données. La CVE-2025-48757 côté Lovable et le contournement d'authentification de Base44 montrent que les vérifications automatiques laissent passer des failles de logique.

Q : Cette checklist vaut-elle pour Lovable Cloud, Bolt ou v0 ?

A : Oui pour l'essentiel. Lovable Cloud repose sur Supabase, le modèle clé anon + RLS y est identique. Un projet Bolt ou v0 branché sur Supabase suit la même logique. Les points 2 à 8 (secrets, authentification, paiements, environnements, RGPD, coûts, tests) valent pour n'importe quelle stack.

Q : Combien de temps faut-il prévoir ?

A : Deux à quatre heures pour dérouler les vérifications, sans écrire de code. Pour les remèdes, comptez de quelques heures (révocation de clés, réglages d'authentification) à quelques jours (politiques RLS complètes, webhooks, environnement de développement séparé), selon ce que la vérification révèle.

Ouvrir, mais ouvrir en confiance

Une application Lovable qui a trouvé ses utilisateurs a déjà réussi le plus difficile : prouver que le produit intéresse quelqu'un. Sécuriser la mise en production, c'est protéger cette réussite dans la durée. Les huit points de cette checklist se vérifient en un après-midi ; les incidents de 2025, de la CVE-2025-48757 à Base44 et Replit, rappellent ce que coûte l'impasse, et montrent aussi que les plateformes elles-mêmes renforcent leurs garde-fous. Faites la vérification avant vos prochains utilisateurs, pas après.

L'agence Platane (https://platane.io) audite des applications générées par IA avant leur ouverture au public : cloisonnement des données, secrets, paiements, environnements et conformité, l'exercice exact décrit ici, formalisé dans notre audit vibe coding.