159 041 projets Lovable analysés : ce que l'étude Crissy Field dit vraiment

Crissy Field, cabinet allemand de sécurité, a analysé 159 041 projets Lovable publiés entre décembre 2025 et septembre 2026, en partenariat avec le Handelsblatt. Sur une partie d'entre eux, des données personnelles étaient lisibles sans connexion. La cause n'est pas une faille de la plateforme : c'est une règle d'accès absente dans la base de données.

Ce que l'étude a mesuré

• 34 545 projets utilisent Supabase comme base de données.
• 24 664 sites envoient des données de leur base dès l'ouverture de la page, sans connexion.
• Des adresses e-mail ont été trouvées dans 10 560 tables, sur 7 403 de ces sites (30 %).
• Parmi les cas graves : un forum avec plus de 80 000 profils et plus de 200 000 messages, un prestataire avec plus de 1 000 fiches de passeports, des billetteries et des restaurants avec adresses, téléphones et informations de paiement.

Les auteurs précisent que les 30 % ne sont pas un taux de fuite confirmé : une adresse e-mail peut être un contact public ou une donnée de test. L'échantillon n'est pas représentatif de toutes les applications Lovable, et la base de données intégrée de Lovable (Lovable Cloud) n'a pas été étudiée.

La cause : une règle d'accès absente

Une application Supabase utilise une clé publique, visible dans le navigateur. C'est normal. Ce qui protège les données, ce sont les règles d'accès définies table par table (RLS, pour Row Level Security). Si une table n'en a pas, ou si une règle autorise la lecture à tout le monde, n'importe qui disposant de la clé publique peut la lire.

Ce que le scan de Lovable couvre, et ce qu'il ne couvre pas

Lovable lance un scan de sécurité gratuit à chaque publication. Il signale notamment les tables sans RLS et les règles qui laissent passer tout le monde, y compris sur un projet Supabase connecté. C'est une première barrière utile : ne publiez jamais en ignorant ses alertes.

Ce scan analyse le code et la configuration. Il ne teste pas l'application en fonctionnement. Il peut confirmer que la RLS est activée sans dire si un client connecté peut lire les commandes d'un autre client. Lovable l'indique lui-même : ces scans ne remplacent pas une revue de sécurité.

Les 5 vérifications avant de mettre de vraies données clients en production

• La RLS est active sur chaque table, sans exception.
• Aucune table contenant des données personnelles n'est lisible par un visiteur non connecté.
• Les formulaires : un visiteur peut envoyer, seul l'administrateur peut relire.
• Chaque utilisateur ne voit que ses propres lignes : un compte A ne lit jamais les données d'un compte B.
• La clé d'administration (service_role) n'apparaît jamais dans le code envoyé au navigateur.

Ces vérifications se refont après chaque évolution importante de l'application.

L'avis de Karim

Lovable fait gagner des semaines sur la construction. Il ne remplace pas la vérification de qui peut lire quoi. Sur les applications que je construis, ce contrôle fait partie de la livraison, pas d'une option. Ce site applique exactement ces règles : vos demandes de devis ne sont lisibles que par moi.