Sécurité d’une application Lovable : les failles à vérifier avant de lancer
Lovable génère en quelques prompts une application React complète, branchée sur Supabase pour la base de données et l’authentification. C’est rapide, et c’est justement le risque : l’interface fonctionne, mais rien ne garantit que les données de vos utilisateurs sont protégées côté serveur.
En 2025, des chercheurs ont montré que plus de 170 applications créées avec Lovable laissaient lire ou modifier leurs données par n’importe qui, faute de règles Row Level Security correctes (CVE-2025-48757). La faille ne venait pas de Lovable lui-même, mais de la configuration des bases générées.
Dix analyses offertes chaque mois, sans carte bancaire. Premier rapport en quelques minutes.
Analyser mon application gratuitementLes failles les plus fréquentes
Tables Supabase sans Row Level Security
La clé « anon » de Supabase est publique : elle est dans le code de votre site. Sans RLS, cette seule clé suffit pour lire toute la table des utilisateurs, des commandes ou des messages.
Politiques trop permissives
Une politique écrite « USING (true) » pour faire marcher l’écran donne l’accès à tout le monde. C’est une correction typique proposée par l’IA quand une requête échoue.
Clé service_role dans le navigateur
La clé service_role contourne toutes les règles. Si elle se retrouve dans une variable VITE_ ou dans le code client, votre base est ouverte.
Contrôles faits uniquement à l’écran
Masquer un bouton « admin » n’empêche personne d’appeler directement l’API. Les droits doivent être vérifiés côté base ou côté serveur.
Ce que Citadel vérifie (15 contrôles actifs)
Analyse du code, des dépendances et des secrets selon OWASP et CWE. Chaque faille arrive avec son explication et le prompt de correction à coller dans votre assistant.
- Clé service_role utilisée dans le code client CWE-798 · A07
- Tables exposées sans Row Level Security activée CWE-284 · A01
- Politiques permissives : USING (true) ou WITH CHECK (true) CWE-284 · A01
- Secrets dans le code et les fichiers de configuration (plus de 100 types de clés) CWE-798 · A07
- Dépendances npm et Composer avec CVE ou avis GHSA publiés A06 · CVSS
- Mots de passe hachés en MD5, SHA-1 ou sans sel CWE-916 · A02
- L’adresse http:// redirige vers https:// CWE-319 · A02
- HSTS présent et de durée suffisante CWE-319 · A05
- Politique CSP présente, sans unsafe-inline ni unsafe-eval CWE-693 · A05
- Protection contre l’intégration dans une autre page (clickjacking) CWE-1021 · A05
- Cookies Secure, HttpOnly et SameSite CWE-614 · CWE-1004
- CORS ouvert à tous les sites avec les cookies CWE-942 · A05
- En-têtes nosniff et Referrer-Policy, version du serveur masquée CWE-693 · CWE-200
- Formulaires envoyés en clair, ou mot de passe passé dans l’adresse CWE-319 · CWE-598
- Formulaires sans jeton anti-CSRF, ou envoyés à un autre domaine CWE-352 · CWE-201
Questions fréquentes
Comment vérifier si mon app Lovable est sécurisée ?
Exportez le code vers GitHub depuis Lovable, puis reliez le dépôt à Citadel ou envoyez-en une archive. L’analyse vérifie les règles RLS, les clés exposées et les dépendances, et vous donne les corrections dans l’ordre.
La clé anon de Supabase visible dans mon site, est-ce grave ?
Non, c’est prévu : elle est faite pour être publique. Ce qui compte, ce sont les règles RLS qui limitent ce qu’elle permet. Sans elles, elle donne accès à tout.
Mon code est-il conservé ?
Non. Il est analysé dans un conteneur isolé, sans accès à Internet, puis supprimé dès la fin de l’analyse. Seuls les résultats sont conservés, secrets masqués.
Combien ça coûte ?
L’offre Gratuite comprend dix analyses par mois, sans carte bancaire. Les offres payantes ajoutent Citadel IA, l’analyse à chaque push et le travail en équipe.
Les autres guides
Sécurité du vibe coding : la checklist avant de mettre votre app en ligne