Checklist sécurité d'une app Lovable : votre app est-elle sécurisée ?
La plateforme Lovable et l'app que vous avez construite dessus sont sécurisées séparément. Lovable recherche les erreurs courantes, mais votre app n'est sûre qu'à la hauteur de ses propres règles d'accès, clés et code serveur. Vérifiez que la sécurité au niveau des lignes est activée sur chaque table exposée et correspond à qui peut voir quoi, qu'aucune clé secrète n'atteint le navigateur, que les paiements sont confirmés sur le serveur, et que quelqu'un surveille l'app en ligne.
- À l'origine de la CVE-2025-48757
- RLS désactivée, ou trop large
- Publiable sans risque
- La clé publishable (anon) de Supabase
- À ne jamais publier
- La clé service-role ou toute autre clé secrète
- À revérifier
- Après chaque modification qui touche aux données ou aux accès
Lovable est-il sécurisé, et cela rend-il mon app sécurisée ?
Lovable indique prendre en charge les exigences SOC 2 et RGPD et publie sa documentation de sécurité dans son centre de confiance. Cela couvre la plateforme Lovable : son infrastructure, ses contrôles d'accès, son personnel. Cela ne couvre pas les règles internes de votre app, puisque c'est vous (avec l'aide de Lovable) qui les avez écrites.
L'analyse de sécurité de Lovable effectue une vérification rapide à chaque publication : une revue de la base de données, un audit des dépendances et un contrôle du serveur MCP. Une analyse plus poussée, lancée manuellement (ou de façon planifiée pour les clients Lovable Enterprise), examine aussi le contrôle d'accès, les points de terminaison non authentifiés, les injections, les secrets divulgués, les paiements, l'authentification et les données personnelles exposées. La documentation de Lovable est claire : ces outils ne peuvent pas garantir une sécurité complète. Considérez l'analyse comme un détecteur de fumée, pas comme une inspection.
Qu'était la CVE-2025-48757, et concerne-t-elle mon app ?
La CVE-2025-48757, publiée en mai 2025, décrit des règles de sécurité au niveau des lignes insuffisantes dans les sites générés par Lovable jusqu'au 15 avril 2025, qui permettaient à des attaquants non authentifiés de lire ou d'écrire dans des tables de la base de données. La National Vulnerability Database américaine lui attribue un score CVSS 3.1 critique de 9,3 et note que Lovable la conteste, au motif que chaque client est responsable de la protection des données de sa propre app.
Le chercheur qui l'a signalée, Matt Palmer, dit avoir analysé 1 645 projets et trouvé 303 points de terminaison vulnérables dans 170 d'entre eux, et que Lovable a livré son analyse de sécurité avec Lovable 2.0 en avril 2025. Quel que soit votre avis sur la controverse, la leçon pratique est la même : si votre app a été générée avant cette date, ou si vous avez modifié des tables depuis, vérifiez vous-même vos règles. Une règle qui existe n'est pas une règle qui est juste.
Que doit couvrir une checklist de sécurité Lovable ?
| Vérification | Pourquoi c'est important | Comment la tester |
|---|---|---|
| RLS activée sur chaque table d'un schéma exposé | Sans elle, Supabase laisse tout rôle disposant d'un droit lire et écrire toute la table | Lancez le Security Advisor de Supabase ; la règle 0013 (rls_disabled_in_public) la signale |
| Des règles qui correspondent à vos règles métier | Une règle comme USING (true) passe une analyse et laisse pourtant tout le monde passer | Connectez-vous en tant qu'utilisateur A, demandez les lignes de l'utilisateur B via l'API, et attendez-vous à ne rien recevoir |
| Tables avec RLS mais sans règle | Elles refusent tout, ce qui se voit comme une fonctionnalité cassée, pas comme une fuite | Règle 0008 de l'Advisor (rls_enabled_no_policy) ; puis écrivez la règle dont la fonctionnalité a besoin |
| Aucune clé secrète dans le navigateur | La clé service-role contourne toutes les règles RLS | Cherchez sb_secret_ ou une ancienne clé service_role dans le JavaScript compilé ; changez toute clé déjà publiée |
| Des contrôles côté serveur sur tout ce qui coûte de l'argent | Le code client peut être modifié par la personne qui l'utilise | Appelez directement votre fonction edge avec un prix ou une offre modifiés et attendez-vous à un refus |
| Limitation du débit sur l'inscription, la connexion et les appels d'IA | Des requêtes illimitées se transforment en abus ou en facture surprise | En préproduction, envoyez 100 requêtes rapides par script et vérifiez que la plupart sont refusées |
| Protection contre les mots de passe compromis et MFA pour les administrateurs | Les mots de passe réutilisés après d'autres fuites sont une porte d'entrée courante | Essayez un mot de passe connu pour avoir fuité lors de l'inscription |
| Un journal d'audit et une supervision des erreurs | Vous ne pouvez pas enquêter sur ce que vous n'avez pas enregistré | Faites une modification d'administration en préproduction et retrouvez-la dans le journal |
Comment corriger les erreurs RLS de Supabase dans une app Lovable ?
Les erreurs RLS sont de deux types opposés, et il est utile de savoir lequel vous concerne.
- Permission refusée (erreur Postgres 42501, ou résultat vide). La RLS est activée et aucune règle n'autorise la requête. C'est la RLS qui fonctionne. Écrivez la règle la plus étroite qui permet à la fonctionnalité de marcher, par exemple les lignes dont la colonne propriétaire est égale à l'identifiant de l'utilisateur connecté.
- Tout fonctionne pour tout le monde. Le cas le plus dangereux. Une règle comme USING (true), ou une RLS non activée, laisse passer n'importe quel utilisateur. L'Advisor de Supabase signale les règles permissives (règle 0024, permissive_rls_policy) et les règles qui existent alors que la RLS est désactivée (règle 0007, policy_exists_rls_disabled).
- Des règles qui lisent les métadonnées utilisateur. Supabase déconseille de fonder des règles sur des métadonnées qu'un utilisateur peut modifier lui-même (règle 0015, rls_references_user_metadata). Utilisez plutôt une table contrôlée par votre serveur, comme une table d'appartenance aux équipes.
Quand vous demandez à Lovable de corriger une règle, refaites ensuite le test à deux utilisateurs. Un prompt qui fait disparaître une erreur peut y parvenir en élargissant l'accès, ce qui est exactement la faille que vous cherchez à éviter.
Quelles clés peut-on exposer sans risque dans une app Lovable ?
La documentation de Supabase indique que la clé publishable (anon) peut être exposée sans risque, car elle n'atteint que ce que la sécurité au niveau des lignes autorise. Une clé secrète, y compris la clé service-role, contourne toutes les règles RLS et ne doit jamais se trouver dans un navigateur, une app distribuée ou un gestionnaire de versions. L'entrée du glossaire sur la clé anon et la clé service-role explique la différence. Les secrets tiers, comme les clés Stripe ou du fournisseur d'e-mail, ont leur place dans les secrets des fonctions edge, pas dans le code de l'app. Voir la gestion des secrets.
À quelle fréquence revérifier une app Lovable en ligne ?
Après chaque modification qui touche aux données, aux accès ou aux paiements, et selon un calendrier pour tout le reste : les dépendances découvrent de nouvelles vulnérabilités, les clés doivent être changées, et de nouvelles tables arrivent avec de nouvelles règles. C'est pourquoi la sécurité fonctionne mieux comme une habitude que comme un audit. Avec nos offres, les contrôles de sécurité, la revue de code et les tests de non-régression s'exécutent sur chaque modification avant qu'elle n'atteigne la production, et un autre ingénieur que l'auteur l'approuve.
Questions fréquentes
Peut-on utiliser Lovable sans risque pour une vraie app professionnelle ?
Lovable est un endroit raisonnable pour construire et façonner une app, et il recherche les erreurs de sécurité courantes. La sûreté de l'app finale dépend de ses propres règles d'accès, clés et code serveur, que vous devriez vérifier avant l'arrivée de vrais utilisateurs et de vraies données. La documentation de Lovable indique que ses analyses ne peuvent pas garantir une sécurité complète.
La clé anon de Supabase dans mon app Lovable pose-t-elle un problème de sécurité ?
Non. Supabase documente la clé publishable (anon) comme exposable sans risque, car elle ne peut atteindre que ce que la sécurité au niveau des lignes autorise. Elle ne devient un problème que si la RLS est désactivée ou trop large. La clé service-role est différente : elle contourne la RLS et ne doit jamais se trouver dans le navigateur.
La CVE-2025-48757 concerne-t-elle encore les apps Lovable ?
La CVE couvre les sites générés par Lovable jusqu'au 15 avril 2025, et Lovable la conteste. Lovable a depuis ajouté une analyse de sécurité. Toute app, ancienne ou récente, peut encore publier une règle trop large : testez donc vos propres tables avec deux comptes utilisateur plutôt que de vous fier à la date.
Combien coûte un audit de sécurité d'une app Lovable ?
De nombreux freelances et sociétés vendent des audits ponctuels à prix fixe. Avec une offre Plutonapps, les contrôles de sécurité et la revue de code s'exécutent sur chaque modification dans le cadre du prix mensuel, en plus de la construction, des tests, des mises en production et de l'exploitation de l'app. Les offres et les prix figurent sur notre page Tarifs.
Puis-je effectuer les contrôles de sécurité moi-même ?
Oui. Lovable lance son analyse rapide à la publication, le Security Advisor de Supabase se trouve dans le tableau de bord de votre projet, et le test à deux utilisateurs de la checklist ne demande que deux comptes de test. Ce qui est plus difficile seul, c'est de continuer à le faire à chaque modification, aussi longtemps que l'app est en ligne.
Tiré de nos réalisations
Termes utilisés sur cette page
Comparatifs et guides associés
- Votre app Lovable ne marche pas en production ? La rendre prête pour la production — Pourquoi les apps qui fonctionnent en aperçu cassent avec de vrais utilisateurs, les vérifications qui les rendent prêtes pour la production, et qui les maintient en service.
- Comment migrer de Lovable Cloud vers votre propre Supabase — Lovable Cloud ou votre propre Supabase, ce que l'export inclut et laisse de côté, et un plan de bascule qui garde la production en service.
- Comment recruter un développeur Lovable (et ce que ça coûte) — Freelances, agences partenaires de Lovable et abonnements d'ingénierie comparés sur le coût, le périmètre et qui exploite l'app ensuite.
- Offres et tarifs
Sources
Chaque fait externe cité sur cette page a été vérifié à partir de la source indiquée le 30 September 2026. Les prix et les offres évoluent : suivez les liens pour connaître les montants actuels.