CVE-2025-48757 est une vulnérabilité de Lovable jugée critique (CVSS 9.3) qui a exposé plus de 170 applications. Le problème : n'importe qui, sans se connecter, pouvait lire —et bien souvent modifier— les données de ta base : noms, emails, clés d'API tierces, et même le statut de paiement. La cause profonde n'est pas un bug caché de Lovable, mais un pattern partagé par presque toutes les apps « vibe-codées » : confier toute la sécurité de la base aux politiques RLS de Supabase… et les laisser incomplètes.
Ce qui s'est vraiment passé
Lovable construit des apps où le navigateur communique directement avec la base de données (Supabase) via des appels REST, en utilisant la clé publique anon. C'est une conception saine tant que chaque table possède des politiques Row-Level Security (RLS) qui décident quelles lignes chaque utilisateur peut lire ou modifier. La vulnérabilité est apparue parce que beaucoup de projets ont été livrés avec des tables sans RLS ou avec un RLS insuffisant. Il suffisait à un attaquant de modifier la requête REST —changer un filtre dans l'URL— pour demander « toutes les lignes » d'une table qui aurait dû être protégée.
Cela a été signalé en mars 2025 par Matt Palmer et Kody Low, et de façon indépendante par Danial Asaria, avec une divulgation publique le 29 mai 2025 (analyse technique, fiche CVE). Tout projet Lovable utilisant une base de données créée le 15 avril 2025 ou avant pouvait être concerné.
Pourquoi ça te concerne même si tu n'utilises pas Lovable
Ce n'est pas un problème propre à Lovable. N'importe quelle app qui communique avec Supabase directement depuis le navigateur —que tu l'aies faite avec Bolt, v0, Cursor ou à la main— dépend du fait que le RLS soit correct sur chaque table. L'app a l'air parfaite, le login fonctionne, mais la vraie sécurité vit dans la base de données, pas dans l'interface. Cacher un bouton dans le frontend ne protège rien : la requête REST est toujours là, à la portée de quiconque sait où regarder.
Comment savoir si ton app est vulnérable
- Ouvre les DevTools (F12) → onglet Network pendant que tu utilises ton app et observe les appels vers
*.supabase.co/rest/v1/. Copie une de ces URL, ouvre-la dans une fenêtre de navigation privée (sans session) et regarde si elle renvoie des données. - Essaie d'en demander trop : si un appel renvoie tes données, retire le filtre de l'URL. S'il te renvoie les lignes d'autres utilisateurs, ton RLS n'est pas efficace.
- Vérifie le dashboard Supabase → Authentication → Policies. Toute table contenant de vraies données affichant « RLS disabled » ou aucune politique est une porte ouverte.
Comment corriger
- Active le RLS sur chaque table, pas seulement sur les « importantes ». La règle, c'est deny by default : sans politique qui l'autorise, personne n'entre.
- Écris des politiques explicites par opération (select/insert/update/delete) liées à
auth.uid(), pour que chaque utilisateur ne touche que ses propres lignes. - N'utilise jamais la clé
service_roledans le frontend : elle contourne totalement le RLS. Cette clé reste uniquement sur le serveur. - Refais le test avec l'étape de navigation privée ci-dessus : si la requête sans session renvoie désormais du vide ou une erreur, tu es sur la bonne voie.
Comment Scanaris le vérifie
Scanaris analyse ton site en lecture seule et détecte l'empreinte de ce pattern : des endpoints Supabase accessibles depuis le navigateur, un CORS permissif, des clés et des tokens exposés dans ton JavaScript, et des données que l'app sert sans session. Colle ton URL et il te dit, en quelques secondes et classé par gravité, ce qui est exposé au grand jour —avant que quelqu'un d'autre ne le trouve.