Une application Lovable Supabase peut exposer toute sa base de données sans que rien ne se voie à l’écran. Le 30 mai 2025, la faille CVE-2025-48757 a été publiée, notée 9,3 sur 10 (CVSS 3.1) par MITRE, qui l’a enregistrée. Selon sa description, des règles d’accès insuffisantes permettaient à un visiteur non connecté de lire ou de modifier des tables de base de données d’applications générées par Lovable jusqu’au 15 avril 2025. La fiche indique que Lovable conteste cette qualification : selon l’éditeur, chaque client est responsable de la protection des données de son application. Les deux lectures se rejoignent sur un point : c’est à vous de vérifier. Voici les sept points à contrôler avant d’ouvrir votre application à de vrais utilisateurs.
Ni Lovable ni Supabase ne sont partenaires de R-CodeLab. Cet article ne dénigre pas ces outils : ils permettent de construire et de tester une idée très vite.
Pourquoi une application Lovable Supabase se protège autrement
Lovable écrit l’interface, qui tourne dans le navigateur de vos visiteurs. Supabase fournit la base de données, l’authentification et le stockage des fichiers. Entre les deux, il n’y a souvent aucun serveur à vous : le navigateur parle directement à la base.
Cette architecture est prévue par Supabase. Elle repose sur deux clés. La clé publique (dite « publishable », anciennement « anon ») est livrée avec l’application : n’importe qui peut la lire, et elle n’ouvre que ce que les règles d’accès autorisent. La clé secrète (anciennement « service_role ») contourne ces règles : elle ne doit jamais quitter un serveur que vous contrôlez. Supabase annonce d’ailleurs l’abandon progressif des anciennes clés « anon » et « service_role » d’ici la fin de 2026 : si votre application les utilise encore, prévoyez la bascule.
Toute la sécurité repose donc sur les règles d’accès par ligne (Row Level Security, ou RLS) : ce sont elles qui disent qu’un client ne voit que ses commandes, et pas celles des autres.
Les 7 points à vérifier sur votre application Lovable Supabase
1. Les règles RLS sont activées sur chaque table
Dans le tableau de bord Supabase, chaque table exposée doit avoir RLS activée, et des règles écrites pour chaque opération : lecture, création, modification, suppression. Dans le schéma exposé par l’API, une table sans RLS est lisible et modifiable par quiconque possède la clé publique, c’est-à-dire tout le monde, tant que les droits accordés par défaut n’ont pas été retirés. Une règle qui autorise tout ne vaut pas mieux.
Test simple : ouvrez votre application dans une fenêtre de navigation privée, sans vous connecter, et regardez ce que les requêtes renvoient dans les outils de développement du navigateur. Si des données d’autres utilisateurs apparaissent, la règle manque.
2. Aucune clé secrète dans le code envoyé au navigateur
Cherchez dans le code, et dans l’historique de votre dépôt Git, toute clé secrète Supabase, clé d’OpenAI, de Stripe ou d’un service d’envoi de courriels. Une clé qui a été publiée une fois doit être renouvelée, pas seulement retirée : elle reste dans les copies et dans l’historique.
3. Chaque utilisateur ne peut agir que sur ses propres données
Ce défaut ne se voit pas en testant avec un seul compte. Créez deux comptes, et vérifiez que le second ne peut ni lire ni modifier ce qu’a créé le premier, y compris en changeant un identifiant dans l’adresse ou dans une requête.
4. Les fichiers stockés ne sont pas publics par défaut
Factures, pièces d’identité, photos : un espace de stockage Supabase déclaré public est lisible par quiconque connaît l’adresse du fichier. Les documents personnels vont dans un espace privé, avec ses propres règles.
5. Les comptes sont à votre nom
Nom de domaine, projet Supabase, compte Lovable, clés d’IA, compte de paiement : chacun doit être ouvert au nom de votre entreprise, avec une adresse que vous contrôlez. Le jour où le prestataire, l’associé ou le stagiaire qui les a créés s’en va, c’est votre application qui part avec lui. Pour les clés d’IA, c’est aussi une question contractuelle : les éditeurs interdisent de revendre ou de partager l’accès à un compte, sauf accord exprès.
6. Les coûts ont un plafond
Un appel d’IA déclenché à chaque affichage de page, ou une boucle qui interroge la base sans fin, se paie à la fin du mois. Posez un plafond de dépense chez chaque fournisseur, et vérifiez qu’un visiteur non connecté ne peut pas déclencher d’appel payant.
7. Vous savez restaurer et redéployer sans la plateforme
Avez-vous une sauvegarde de la base que vous savez restaurer ? Le code est-il dans un dépôt Git qui vous appartient ? Pourriez-vous déployer l’application ailleurs si la plateforme changeait ses prix ou ses conditions ? Si la réponse est non, c’est le premier chantier, avant toute nouvelle fonction.
Récapitulatif : comment vérifier chaque point
| Point | Comment le vérifier | Si ce n’est pas fait |
|---|---|---|
| Règles RLS | tableau de bord Supabase, table par table | toute la table est lisible et modifiable avec la clé publique |
| Clés secrètes | recherche dans le code et l’historique Git | la clé doit être renouvelée, pas seulement retirée |
| Données de chaque utilisateur | test avec deux comptes | un client voit les données d’un autre |
| Fichiers stockés | réglages des espaces de stockage | les documents sont lisibles par leur adresse |
| Comptes | titulaire de chaque service | l’application dépend d’une autre personne |
| Coûts | plafond chez chaque fournisseur | facture imprévue en fin de mois |
| Restauration | essai de restauration de la sauvegarde | aucune reprise possible après un incident |
Et si votre application vient de Bolt, v0 ou Base44 ?
Les outils changent, les questions restent les mêmes. Quel que soit le générateur, demandez-vous où se trouve la base de données, quelles règles la protègent, où sont rangées les clés, à qui appartiennent les comptes et comment récupérer le code. Certains outils produisent un code que vous pouvez exporter et héberger où vous voulez ; d’autres gardent l’application et ses données sur leur propre plateforme, ce qui rend la reprise plus difficile. Vérifiez-le avant d’y confier des données de clients.
Le code généré par IA n’est pas moins sûr par nature, mais il n’est pas relu
En juillet 2025, Veracode a publié un test de plus de 100 grands modèles de langage sur des tâches de programmation en Java, Python, C# et JavaScript : 45 % des échantillons de code produits introduisaient une faille parmi les plus connues (liste OWASP Top 10). C’est une étude en laboratoire, pas un relevé d’applications en production, mais elle dit l’essentiel : un modèle écrit du code qui fonctionne, pas du code qui a été relu.
Les plateformes elles-mêmes ne sont pas à l’abri. En juillet 2025, les chercheurs de Wiz ont signalé une faille dans Base44 qui permettait de créer un compte sur une application privée ; elle a été corrigée en moins de 24 heures, sans trace d’exploitation selon Wix, propriétaire de Base44. Ce n’était pas une erreur du code des utilisateurs, mais un rappel : une application exploitée se surveille.
Les signes qu’il est temps de faire relire votre application
- vos premiers clients paient, ou vont payer, dans l’application ;
- elle contient des données personnelles : noms, adresses, documents, santé ;
- une deuxième personne doit pouvoir y travailler ;
- chaque demande faite à l’IA casse une fonction qui marchait ;
- vous ne savez plus dire quels services sont branchés, ni qui les paie.
Un seul de ces signes suffit pour faire relire le code par un développeur, avant qu’un incident ne le fasse pour vous.
Données personnelles : ce qu’impose une fuite
Si votre application Lovable Supabase contient des données de clients et qu’une fuite est constatée, c’est vous, en tant que responsable du traitement, qui devez la notifier à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques (article 33 du RGPD). Mieux vaut vérifier les sept points avant d’avoir à le faire.
Questions fréquentes
Supabase est-il sûr ?
Supabase fournit les outils de protection : règles RLS, authentification, séparation des clés. Ils ne protègent que s’ils sont configurés. La question utile est donc : les règles de votre projet sont-elles écrites et testées ?
Faut-il abandonner Lovable ?
Non. Lovable reste un bon outil pour construire et tester vite. Ce qui change avec de vrais utilisateurs, c’est qu’une personne doit relire ce qui a été généré, et en répondre.
Peut-on sortir le code de Lovable ?
Oui : Lovable permet de synchroniser le projet avec un dépôt GitHub. Faites-le tôt, sur un compte à votre nom.
Combien coûte une reprise ?
Cela dépend de l’application. Nous commençons par un diagnostic à prix fixe, annoncé avant toute commande, qui classe les risques et chiffre la suite par écrit.
Pour aller plus loin
- Application web sur mesure : notre offre de développement et de reprise.
- IA locale et open weight : utiliser l’IA sans envoyer vos données hors d’Europe.
- Automatisation et IA pour les TPE et PME : ce qui s’automatise vraiment.
Faire reprendre votre application
Vous avez construit votre application avec Lovable, Bolt ou un autre générateur, et vous voulez l’ouvrir sereinement ? R-CodeLab, basé en Vendée, vérifie ces sept points, corrige ce qui bloque et remet les comptes à votre nom. Premier échange gratuit : nous vérifions d’abord que votre code peut être récupéré.
Sources
- CVE-2025-48757, fiche officielle : description, date de publication, note, contestation de l’éditeur.
- Matt Palmer, publication du chercheur : chronologie de la découverte.
- Supabase, clés d’API : clé publique, clé secrète, abandon des anciennes clés.
- Supabase, Row Level Security : règles d’accès par ligne.
- Supabase, espaces de stockage : espaces publics et privés.
- Lovable, synchronisation avec GitHub : récupérer le code du projet.
- Wiz Research, faille Base44 : contournement d’authentification, juillet 2025.
- Veracode, 2025 GenAI Code Security Report : failles dans le code généré par IA.
- RGPD, article 33, sur le site de la CNIL : notification d’une violation de données.
Sources vérifiées le 28 septembre 2026.
