Lovable : 7 403 applications laissaient lire des passeports et des paiements sans aucune connexion

Le chiffre vient d'un cabinet unique, Crissy Field, basé en Allemagne, qui dit avoir scanné 159 041 projets Lovable entre décembre 2025 et septembre 2026. Sur ces projets, 24 664 utilisaient une base Supabase, et une partie répondait sans demander de connexion. Les chercheurs ont dénombré environ 7 403 sites qui livraient des données personnelles à quiconque ouvrait l'application : adresses email, contrats, factures, communications internes, et dans certains cas des numéros de passeport et des informations de paiement. Plus de 200 000 messages de conversation figuraient dans le lot.

La méthodologie mérite d'être nommée avant d'être relayée. Crissy Field vend des outils de scan. Le périmètre est celui des projets Lovable accessibles publiquement sur la fenêtre déclarée, pas celui de la base installée complète, que Lovable chiffrait à 60 millions de projets au moment de sa levée de Série C en août 2026. Un chiffre produit par un fournisseur de sécurité sur un échantillon qu'il a lui-même délimité n'est pas une mesure de la prévalence réelle du défaut sur l'ensemble de la plateforme. Il mesure ce que le scanner a vu.

Le défaut technique n'est pas dans Lovable à proprement parler. Les applications générées embarquent par défaut un backend Supabase, et Supabase repose sur les Row Level Security policies : un mécanisme de contrôle d'accès qui doit être configuré explicitement, table par table. Quand il ne l'est pas, la table est ouverte. Le code généré par le modèle omet régulièrement cette configuration, et l'utilisateur qui a décrit son idée en langage naturel n'a aucune raison de savoir qu'une ligne de politique manque.

Sur le calendrier du correctif, la date de référence est le 30 octobre 2026. C'est à cette date que Supabase a modifié les grants par défaut appliqués aux nouvelles tables, de sorte que le rôle anonyme n'hérite plus automatiquement d'un accès. La correction s'applique aux tables créées après ce changement. Les projets existants, eux, restent dans l'état où leur configuration les a laissés tant que leur propriétaire n'intervient pas.

Avril

Ce n'est pas le premier passage de Lovable dans cette rubrique. En avril 2026, un chercheur identifié sous le pseudonyme @weezerOSINT avait divulgué une faille BOLA, Broken Object Level Authorization, qui permettait depuis un simple compte gratuit de lire le code source, les identifiants de base de données, les clés d'API et l'historique de conversation d'autres projets. BOLA occupe la première place de l'OWASP API Security Top 10. Les projets étaient restés exposés 48 jours après la divulgation, et le correctif de l'époque avait traité les nouveaux projets avant les anciens, exactement la logique qui se répète ici.

À l'époque du BOLA, Lovable était valorisée 6,6 milliards de dollars et revendiquait huit millions d'utilisateurs. En août, Menlo Ventures et le Scaleup Europe Fund ont mené une Série C de 400 millions de dollars portant la valorisation à 13,3 milliards. La trajectoire financière et la trajectoire sécurité avancent en parallèle sans se croiser.

Supabase sûr par défaut, Lovable par-dessus

Les chiffres qui circulent sur le phénomène ne sont pas comparables entre eux et ne devraient pas être additionnés. Le scan de Crissy Field porte sur des projets Lovable publiquement accessibles. D'autres relevés antérieurs évoquaient un nombre bien plus faible d'applications vivantes exposées via le même défaut RLS, et un autre cabinet, Sentris, a publié en août 2026 un scan portant sur 2 144 dépôts publics utilisant Supabase. Périmètres différents, outils différents, objectifs commerciaux différents. Mettre ces nombres côte à côte produit une inflation qui ne dit rien de l'ampleur réelle.

Pour une DSI, l'objet du problème n'est pas Lovable en tant que fournisseur mais ce qui se construit sous le radar. Des employés de grandes entreprises technologiques figuraient parmi les détenteurs de comptes actifs identifiés lors de l'épisode d'avril. Une application montée en un week-end par une équipe métier pour collecter des pièces justificatives, qui demande un passeport et le stocke dans une table sans politique d'accès, ne passe par aucune revue d'architecture. Elle existe, elle a une URL, elle est indexée.

Rien dans le relevé de Crissy Field ne nomme les clients concernés, ni la répartition par secteur, ni combien des 7 403 sites étaient encore actifs au moment du scan par opposition à des projets abandonnés mais toujours en ligne. Ces absences ne contredisent pas le chiffre. Elles en fixent la portée.

Le passage du modèle de langage à la production tient sur une politique RLS que personne n'a écrite. C'est tout le défaut, et c'est aussi tout l'argument commercial du langage naturel comme interface de développement.