Les vulnérabilités de sécurité de Lovable en 2026 : clés exposées, RLS manquante, et ce que les audits détectent

J'ai passé les trois derniers mois à auditer des applications que des clients nous ont apportées après avoir construit leurs MVPs sur Lovable. Le schéma est tellement cohérent que c'en est presque ennuyeux : clés de service Supabase exposées dans les bundles clients, zéro politique RLS, secrets OpenAI et Stripe codés en dur assis là dans le JavaScript pour que n'importe qui ayant accès aux DevTools les récupère. À chaque fois.

Ce n'est pas un article critique envers Lovable. La plateforme est genuinely impressionnante pour le prototypage. Mais il y a un canyon de taille gigantesque entre « démo fonctionnelle » et « application prête pour la production », et Lovable ne vous dit pas grand-chose sur ce qui se trouve dans ce canyon. Un chercheur communautaire a audité 50 applications construites par l'IA et a trouvé les mêmes cinq erreurs de sécurité dans presque toutes. Un autre développeur a scanné 200+ sites codés à la vibe et a trouvé un score de sécurité moyen de 52 sur 100 -- les pires contrevenants étant concentrés dans les applications Lovable + Supabase spécifiquement.

Parcourons chaque vulnérabilité que nous continuons à trouver, pourquoi les propres outils de Lovable les manquent, et exactement comment corriger chacune.

Table des matières

Lovable Security Vulnerabilities 2026: Exposed Keys, Missing RLS, and What Audits Catch

L'architecture qui crée le problème

Pour comprendre pourquoi les applications Lovable sont disproportionnément affectées, vous devez comprendre l'architecture. Lovable utilise exclusivement Supabase comme backend. Il n'y a pas d'option Firebase, pas de backend personnalisé, pas de trappe de secours. Lorsque vous construisez quelque chose dans Lovable, il génère un frontend React qui communique directement avec l'API REST de Supabase à l'aide de la bibliothèque client.

Supabase est conçu de sorte que la clé anon soit sûre d'être exposée publiquement -- c'est essentiellement un identifiant de projet. Le modèle de sécurité repose entièrement sur les politiques de sécurité au niveau des lignes (RLS) au niveau de PostgreSQL. Pensez-y de cette façon :

Composant Destiné à être public ? Ce qui vous protège
URL Supabase Oui Rien de nécessaire -- c'est juste une URL
Clé anon Oui Politiques RLS sur chaque tableau
Clé service_role Absolument pas Doit rester côté serveur uniquement
Chaîne de connexion à la base de données Non Ne jamais exposer aux clients

Le problème est que l'IA de Lovable génère du code qui traite souvent tous ces éléments de la même façon. Elle met la clé anon dans le frontend (ok), mais crée ensuite des tables sans activer RLS (catastrophique). Parfois, elle met aussi la clé service_role dans le code client (game over). Comme l'a dit un développeur sur Reddit : « L'IA fait ce que vous demandez. Elle ne pense juste jamais à ce que vous n'avez pas demandé. »

Vulnérabilité 1 : clés Supabase exposées dans le code client

Chaque application Lovable initialise le client Supabase quelque chose comme ceci :

// src/integrations/supabase/client.ts
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'https://xyzcompany.supabase.co'
const supabaseAnonKey = 'eyJhbGciOiJIUzI1NiIs...'

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

Le fait que la clé anon soit ici va bien -- c'est par conception. Le problème se présente sous deux formes :

La fuite de clé `service_role`

Nous avons vu du code généré par Lovable où la clé service_role finit dans du code côté client, généralement parce que quelqu'un a invité l'IA avec quelque chose comme « faites que ça marche même si RLS le bloque ». La solution de l'IA ? Utilisez la clé admin. La clé service_role contourne complètement toutes les politiques RLS. Si elle est dans votre bundle frontend, n'importe qui peut l'extraire et avoir accès en lecture/écriture complet à toute votre base de données.

Le fichier `.env` committalisé sur Git

Les projets Lovable déployés sur GitHub ont fréquemment des fichiers .env committalisés dans le référentiel. Même si le référentiel est privé maintenant, s'il a déjà été public -- ne serait-ce qu'une minute -- ces clés sont compromises. Les bots scrapent GitHub constamment pour exactement ce schéma.

Comment vérifier :

# Chercher dans votre codebase les clés service_role
grep -r "service_role" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env" .

# Vérifier l'historique git pour les secrets accidentellement committalisés
git log --all -p -- '*.env'

Comment corriger : Supprimez immédiatement la clé service_role de tout code client. Faites tourner la clé dans votre tableau de bord Supabase (Paramètres → API). Utilisez la clé uniquement dans du code côté serveur -- Supabase Edge Functions, une route d'API Next.js, ou un backend séparé.

Vulnérabilité 2 : politiques RLS manquantes ou cassées

C'est la grosse. CVE-2025-48757 a exposé 303 points de terminaison vulnérables sur 170+ applications construites avec Lovable. Selon Escape.tech, 83% des bases de données Supabase exposées impliquent des erreurs de configuration RLS.

Voici ce qui se passe par défaut lorsque Lovable crée une table :

-- Ce que Lovable génère souvent
CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users(id),
  full_name TEXT,
  email TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Remarquez ce qui manque ? RLS n'est pas activé.
-- Cette table est entièrement lisible et modifiable par quiconque possède la clé anon.

Sans RLS, votre base de données Supabase est essentiellement une API publique. N'importe qui qui connaît l'URL de votre projet et la clé anon -- tous deux dans votre code frontend -- peut faire ceci :

// Console du navigateur d'un attaquant
const { data } = await supabase.from('user_profiles').select('*')
// Retourne les données de CHAQUE utilisateur

await supabase.from('user_profiles').delete().neq('id', '')
// Supprime tout

Trois saveurs d'échecs RLS

Mode d'échec Ce qui se passe Sévérité
RLS pas du tout activé Accès en lecture/écriture public complet Critique
RLS activé mais pas de politiques définies Personne ne peut accéder à quoi que ce soit (l'application casse) Élevé (force les devs à désactiver RLS)
Politiques trop permissives (par ex., USING (true)) Semble sécurisé, en réalité non Élevé

Le troisième est particulièrement insidieux. Nous avons vu Lovable générer des politiques comme celle-ci lorsqu'on l'a invité à « corriger les autorisations » :

CREATE POLICY "Allow all access" ON user_profiles
  FOR ALL
  USING (true)
  WITH CHECK (true);

C'est du théâtre RLS. C'est activé, c'a une politique, et ça ne fait absolument rien.

À quoi ressemble une bonne politique :

-- Activer RLS
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

-- Les utilisateurs ne peuvent lire que leur propre profil
CREATE POLICY "Users read own profile" ON user_profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Les utilisateurs ne peuvent mettre à jour que leur propre profil
CREATE POLICY "Users update own profile" ON user_profiles
  FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

-- Seuls les utilisateurs authentifiés peuvent insérer, et seulement pour eux-mêmes
CREATE POLICY "Users insert own profile" ON user_profiles
  FOR INSERT
  WITH CHECK (auth.uid() = user_id);

Lovable Security Vulnerabilities 2026: Exposed Keys, Missing RLS, and What Audits Catch - architecture

Vulnérabilité 3 : secrets API tiers codés en dur

Celui-ci me fait grimacer à chaque fois. Nous trouvons régulièrement des clés OpenAI (sk-...), des clés secrètes Stripe (sk_live_...), des clés SendGrid, et d'autres identifiants codés en dur directement dans les composants React.

// Réellement trouvé dans un fichier généré par Lovable
const openai = new OpenAI({
  apiKey: 'sk-proj-abc123...',  // Ceci est dans votre bundle de navigateur
})

N'importe qui qui ouvre DevTools, va dans l'onglet Sources, et cherche sk- ou sk_live obtient vos clés. Les attaquants automatisent cela. Il y a des bots qui parcourent spécifiquement les bundles JavaScript à la recherche de ces schémas.

L'impact financier est réel. Nous avons eu un client venir à nous après qu'une clé OpenAI exposée ait entraîné 4 200 $ de frais sur un week-end. Les clés secrètes Stripe sont pires -- elles accordent l'accès complet pour traiter les remboursements, voir les données des clients, et modifier les abonnements.

La correction : Déplacez tous les appels API tiers vers des fonctions côté serveur. Supabase Edge Functions fonctionne bien pour cela :

// supabase/functions/openai-proxy/index.ts
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'

serve(async (req) => {
  const { prompt } = await req.json()
  
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${Deno.env.get('OPENAI_API_KEY')}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: prompt }],
    }),
  })
  
  return new Response(JSON.stringify(await response.json()))
})

Vulnérabilité 4 : en-têtes de sécurité manquants

Le scan de 200+ sites a trouvé que la plupart des applications déployées par Lovable sont livrées sans aucun en-tête de sécurité. Pas de Content-Security-Policy. Pas de Strict-Transport-Security. Pas de X-Frame-Options. Pas de X-Content-Type-Options.

Cela pourrait sembler mineur comparé à une base de données exposée, mais les en-têtes manquants permettent :

  • Clickjacking -- votre application peut être intégrée dans une iframe sur un site malveillant
  • Amplification XSS -- sans CSP, les scripts injectés n'ont aucune restriction
  • Attaques de reniflage de type MIME -- les navigateurs peuvent interpréter les fichiers comme du code exécutable
  • Attaques de rétrogradation -- sans HSTS, le trafic peut être intercepté
En-tête Objectif Défaut Lovable
Content-Security-Policy Prévient XSS, contrôle le chargement des ressources Manquant
Strict-Transport-Security Force HTTPS Manquant
X-Frame-Options Prévient le clickjacking Manquant
X-Content-Type-Options Prévient le reniflage MIME Manquant
Referrer-Policy Contrôle les informations de référent Manquant
Permissions-Policy Contrôle les fonctionnalités du navigateur Manquant

Vulnérabilité 5 : pas de validation ou de désinfection des entrées

Les formulaires générés par Lovable envoient généralement l'entrée utilisateur directement à Supabase sans aucune validation. Pas de vérifications de longueur, pas de validation de type, pas de désinfection du HTML ou de contenu de type SQL.

Alors que la couche PostgREST de Supabase prévient les injections SQL traditionnelles, le manque de validation des entrées permet néanmoins :

  • XSS stocké via HTML non désinfecté dans des champs de texte
  • Déni de service via des charges utiles extrêmement grandes
  • Abus de logique métier (par ex., quantités négatives, prix de 0,00 $)
  • Corruption de données à partir de types inattendus

Ce que le scan de sécurité intégré de Lovable vérifie réellement

Lovable a bien une fonctionnalité « Security Scan » intégrée accessible depuis le tableau de bord. Crédit où c'est dû -- elle existe. Mais voici ce qu'elle couvre réellement par rapport à ce qu'elle ne couvre pas :

Vérification Scan intégré Audit de production
Erreurs de syntaxe de base ✅ ✅
CVE de dépendances connues Partiel ✅
Secrets codés en dur dans la source ❌ ✅
RLS activé sur toutes les tables ❌ ✅
Justesse de la politique RLS ❌ ✅
Exposition de clé service_role ❌ ✅
En-têtes de sécurité ❌ ✅
Couverture de validation des entrées ❌ ✅
Examen de la configuration d'authentification ❌ ✅
Politiques de bucket de stockage ❌ ✅
Limitation de débit ❌ ✅
Drapeaux de sécurité des cookies ❌ ✅

Le scan intégré est superficiel au mieux. Il ne attrapera pas les vulnérabilités qui sont réellement exploitées.

Ce qu'un audit de production détecte que la plateforme ne détecte pas

Lorsque nous faisons un audit de sécurité de production pour un client qui a construit sur Lovable, voici ce que nous trouvons et corrigeons généralement. C'est la liste réelle, à partir d'engagements réels :

Couche de base de données

  • Tables avec RLS désactivé (moyenne : 60-70% des tables)
  • Politiques RLS utilisant true comme condition
  • Politiques manquantes pour les opérations DELETE (les devs oublient la suppression)
  • Pas de politiques sur les tables de jonction/jointure
  • Buckets de stockage définis publiquement sans restriction de téléchargement
  • Index manquants sur les colonnes utilisées dans les conditions de politique RLS (performance + sécurité)

Couche d'authentification

  • Secrets JWT faibles (les défauts de Supabase vont bien, mais parfois les gens les changent)
  • Exigences de confirmation d'email manquantes
  • Pas de limitation de débit sur les points de terminaison d'authentification
  • Flux de réinitialisation de mot de passe sans expiration appropriée du jeton
  • Erreurs de configuration d'URL de redirection OAuth

Couche de code client

  • Clés service_role dans les bundles frontend
  • Clés API tiers codées en dur dans les composants
  • Fichiers .env committalisés dans l'historique git
  • Journalisation de débogage qui expose les données utilisateur dans la console
  • Messages d'erreur qui divulguent les informations du schéma de base de données

Couche d'infrastructure

  • Aucun en-tête de sécurité
  • Cookies sans drapeaux Secure, HttpOnly, ou SameSite
  • Informations de version de serveur exposées
  • Pas de configuration CORS (accepte les demandes de n'importe quelle origine)
  • Dépendances avec des CVE connues qui n'ont pas été mises à jour depuis des mois

Une application Lovable typique que nous auditons a besoin de 15-25 corrections avant d'être prête pour la production. La plupart d'entre elles prennent moins d'une heure chacune, mais vous devez d'abord savoir qu'elles existent.

L'incident Moltbook : une étude de cas du monde réel

En janvier 2026, les chercheurs en sécurité de Wiz ont découvert que Moltbook -- un réseau social alimenté par l'IA -- avait toute sa base de données Supabase exposée via un client mal configuré. La clé anon était dans le JavaScript frontend (normal), mais RLS n'était pas configuré sur les tables critiques (catastrophique).

Le résultat ? 1,5 million de clés API étaient accessibles. Pas seulement les données utilisateur -- les clés API réelles appartenant aux utilisateurs qui avaient connecté leurs comptes OpenAI, Anthropic, et autres. Accès complet en lecture et écriture à chaque table. Un chercheur pouvait parcourir toute la base de données juste en utilisant le client Supabase dans une console du navigateur.

La chronologie de la divulgation était serrée -- le responsable de Moltbook a corrigé les tables critiques en quelques heures après avoir été contacté. Mais la fenêtre de dommages était inconnue. Depuis combien de temps la base de données était-elle exposée avant que quelqu'un ne la vérifie ? Personne ne le sait.

C'est le schéma Lovable + Supabase joué à grande échelle. La plateforme génère du code fonctionnant. Elle ne génère juste pas du code sécurisé.

Comment corriger une application Lovable avant la production

Voici la liste de contrôle que nous utilisons. Vous pouvez faire la plupart de cela vous-même si vous êtes à l'aise avec SQL et le tableau de bord de Supabase :

Étape 1 : auditer chaque table pour RLS

-- Exécutez ceci dans l'éditeur SQL Supabase pour trouver les tables sans RLS
SELECT schemaname, tablename, rowsecurity 
FROM pg_tables 
WHERE schemaname = 'public';

Toute table où rowsecurity est false a besoin d'une attention immédiate.

Étape 2 : chercher dans votre codebase les secrets

# Chercher les schémas de secret courants
grep -rn 'sk-' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'sk_live' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'service_role' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'SUPABASE_SERVICE' --include='*.ts' --include='*.tsx' --include='*.env' .

Étape 3 : écrire des politiques RLS appropriées

Pour chaque table, écrivez des politiques explicites pour SELECT, INSERT, UPDATE, et DELETE. Utilisez toujours les vérifications auth.uid() :

-- Modèle pour une table appartenant à l'utilisateur
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

CREATE POLICY "select_own" ON your_table FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "insert_own" ON your_table FOR INSERT
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "update_own" ON your_table FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "delete_own" ON your_table FOR DELETE
  USING (auth.uid() = user_id);

Étape 4 : déplacer les appels API côté serveur

Tout appel API tiers qui nécessite une clé secrète doit s'exécuter dans une Supabase Edge Function ou un backend séparé. C'est non négociable.

Étape 5 : ajouter des en-têtes de sécurité

Si vous déployez sur Netlify, Vercel, ou Cloudflare, ajoutez des en-têtes via leur configuration. Pour Netlify, créez un fichier _headers. Pour une application Next.js, ajoutez-les dans next.config.js.

Étape 6 : considérer une migration de framework

Pour tout ce qui dépasse un MVP, nous recommandons souvent de migrer le code React généré par Lovable dans un vrai projet Next.js ou Astro. Cela vous donne des routes d'API côté serveur, une gestion appropriée des variables d'environnement, un middleware pour les vérifications d'auth, et un vrai pipeline de construction. C'est plus de travail initialement, mais la posture de sécurité est jour et nuit.

Outils pour le scanning automatisé

Plusieurs outils ont émergé spécifiquement pour auditer les applications générées par l'IA :

Outil Ce qu'il vérifie Coût
Ship Safe (npx ship-safe audit .) RLS, exposition service_role, buckets de stockage, CVE de dépendances Gratuit, open-source
Vibe App Scanner (vibeappscanner.com) Scan de sécurité complet pour les applications construites par l'IA Scan de démarrage gratuit
Snyk Vulnérabilités de dépendances, scanning de code Niveau gratuit disponible
Tableau de bord Supabase → Auth → Policies Éditeur de politique RLS visuel Inclus avec Supabase

Ship Safe est celui avec lequel je commencerais. Il s'exécute localement, rien ne quitte votre machine, et c'est spécifiquement construit pour les erreurs de configuration Supabase que les outils d'IA créent :

npx ship-safe audit .

Il signalera RLS désactivé, clés service_role dans le code client, buckets de stockage ouverts, configuration d'auth faible, secrets codés en dur, et CVE de dépendances.

FAQ

Est-ce que la clé anon de Supabase est sûre d'être exposée dans le code frontend ?

Oui -- mais seulement si vous avez des politiques RLS appropriées sur chaque table. La clé anon est conçue pour être publique. C'est comme un identifiant de projet. La sécurité vient des politiques RLS qui contrôlent ce que cette clé peut réellement accéder. Sans RLS, la clé anon donne à quiconque accès complet à la base de données.

Lovable active-t-il RLS par défaut lors de la création de tables ?

Non. Depuis début 2026, Lovable crée des tables Supabase sans activer RLS par défaut. C'est l'écart de sécurité le plus important de la plateforme. Vous devez manuellement activer RLS et écrire des politiques pour chaque table après que Lovable les génère. CVE-2025-48757 était une conséquence directe de ce comportement par défaut.

Comment vérifier si mon application Lovable a des secrets exposés ?

Ouvrez votre application déployée dans un navigateur, ouvrez DevTools (F12), allez à l'onglet Sources, et cherchez dans tous les fichiers pour sk-, sk_live, service_role, et tous les préfixes de clé API pour les services que vous utilisez. Exécutez également npx ship-safe audit . localement sur votre codebase pour la détection automatisée.

Le scan de sécurité intégré de Lovable peut-il détecter les problèmes RLS ?

Le scan de sécurité intégré ne vérifie pas les erreurs de configuration RLS, les politiques manquantes, ou les clés service_role exposées. Il couvre les problèmes au niveau du code de base mais manque les vulnérabilités de base de données et d'infrastructure qui représentent le risque le plus élevé. Vous avez besoin d'outils externes pour une vrai évaluation de sécurité.

Qu'est-ce qui s'est passé avec CVE-2025-48757 ?

CVE-2025-48757 était une divulgation de vulnérabilité qui a identifié 303 points de terminaison API vulnérables sur 170+ applications construites avec Lovable. La cause racine était Lovable créant des tables Supabase sans activer RLS, laissant des bases de données entières accessibles à quiconque ayant la clé anon accessible publiquement. Elle a souligné la nature systémique du problème.

Devrais-je migrer loin de Lovable pour les applications de production ?

Pas nécessairement. Lovable est excellent pour le prototypage rapide et la construction des MVPs. Mais le code généré a besoin d'un durcissement de sécurité significatif avant l'utilisation en production. De nombreuses équipes utilisent Lovable pour construire la version initiale, puis migrent vers un framework approprié avec le rendu côté serveur, la gestion appropriée des secrets, et le middleware de sécurité. C'est une approche raisonnable.

Combien de temps faut-il pour sécuriser une application Lovable pour la production ?

Pour une application typique avec 10-20 tables, compter 2-5 jours de travail concentré pour auditer toutes les politiques RLS, déplacer les secrets côté serveur, ajouter des en-têtes de sécurité, valider les entrées, et tester tout. Les applications plus complexes avec buckets de stockage, abonnements en temps réel, et rôles utilisateurs multiples peuvent prendre plus de temps. Ce n'est pas insurmontable, mais ce n'est pas une tâche d'une heure non plus.

D'autres générateurs d'applications alimentées par l'IA comme Bolt ou Cursor sont-ils plus sûrs que Lovable ?

Le scan de 200+ sites a trouvé que les vulnérabilités de sécurité étaient concentrées dans les applications Lovable + Supabase spécifiquement. Les applications Bolt, Replit, et Cursor/Cline n'ont pas montré le même schéma d'erreurs de configuration RLS. Cela ne signifie pas qu'elles sont parfaitement sécurisées -- tout code généré par l'IA a besoin d'un examen -- mais l'intégration Supabase spécifique à Lovable crée une classe unique de vulnérabilités d'exposition de base de données que d'autres outils n'ont pas.