Checklist sécurité Lovable : les 12 points à vérifier avant de publier
Avant de publier votre app Lovable, passez ces 12 vérifications de sécurité : Row Level Security (la sécurité au niveau des lignes de Supabase), gestion des clés d’API, authentification et protection des données. Chaque point est classé par gravité, pour que vous sachiez quoi corriger en premier.
Dix ans CTO d’un SaaS à 10 M$ d’ARR à San Francisco, au service d’entreprises du Fortune 500, dans l’IA réglementée et les données personnelles. Un passé dans la cyberdéfense. Aujourd’hui CEO de BWorlds, il aide créateurs d’apps et entreprises à faire de leurs apps nées du vibe coding de vrais produits.
À corriger en priorité
6 vérificationsLa Row Level Security (RLS) est activée sur toutes les tables Supabase
C’est la vérification la plus importante de toutes. Sans RLS, les tables de votre base sont accessibles publiquement via l’API Supabase. Ouvrez l’éditeur SQL et lancez : SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; Chaque table qui contient des données utilisateurs doit afficher true.
Les policies RLS s’appuient sur auth.uid(), jamais sur un identifiant envoyé par le navigateur
Une policy RLS (une règle d’accès) doit identifier l’utilisateur connecté avec auth.uid(). Ne faites jamais confiance à un identifiant d’utilisateur envoyé depuis le navigateur. Une policy comme USING (user_id = auth.uid()) garantit que chacun n’accède qu’à ses propres données.
La clé service role n’apparaît pas dans le code du frontend
La clé service role de Supabase contourne toutes les policies RLS. Elle ne doit apparaître que dans les Edge Functions (côté serveur). Cherchez sa valeur dans l’ensemble du code pour vérifier qu’elle n’est exposée nulle part.
Toutes les clés d’API sont rangées dans les Secrets de Lovable
Clés Stripe, clés OpenAI, identifiants de n’importe quel service tiers : tout doit être stocké dans les Secrets de Lovable, jamais écrit en dur dans les fichiers source. Lovable vous prévient quand vous collez une clé dans le chat, mais relisez toujours le code généré.
L’inscription exige la confirmation de l’adresse e-mail
Activez la confirmation par e-mail dans les réglages Auth de Supabase. Sans elle, n’importe qui peut créer des comptes avec de fausses adresses et accéder à votre app. C’est la protection de base contre le spam.
Les routes protégées renvoient les visiteurs non connectés vers la connexion
Chaque page qui affiche des données utilisateurs doit vérifier qu’une session valide existe. Ouvrez une fenêtre de navigation privée et allez directement sur /dashboard, /settings ou toute autre route réservée aux utilisateurs connectés. Si la page s’affiche sans connexion, vous avez une faille.
Important
3 vérificationsLes policies INSERT et UPDATE comportent une clause WITH CHECK
Sans WITH CHECK, un utilisateur peut parfois insérer des lignes qui ne devraient pas lui appartenir. Chaque policy RLS d’INSERT et d’UPDATE doit comporter WITH CHECK (user_id = auth.uid()).
La Security View a été passée en revue avant de publier
La Security View intégrée à Lovable regroupe les constats de son analyse de la base de données et de sa revue du code. Ouvrez-la et traitez tous les éléments Error et Warning avant de publier.
Le CORS n’autorise que votre domaine
Vérifiez que votre projet Supabase n’accepte que les requêtes venant du domaine de votre app, et pas de n’importe quelle origine. Cela empêche d’autres sites d’appeler votre API avec les identifiants de vos utilisateurs.
Recommandé
3 vérificationsLes messages d’erreur ne dévoilent rien du système
Provoquez des erreurs dans votre app et regardez ce que voient les utilisateurs. Traces d’exécution, messages d’erreur de la base de données, chemins de fichiers : rien de tout cela ne doit être visible en production. Affichez plutôt des messages génériques.
Le nombre de requêtes est limité sur les routes d’authentification
Sans limite du nombre de requêtes, un attaquant peut essayer des mots de passe en masse ou multiplier les inscriptions. Supabase a des limites intégrées, mais vérifiez qu’elles sont bien actives dans les réglages de votre projet.
Une revue de sécurité complète a été lancée à la demande
Demandez à Lovable « Fais une revue de sécurité de mon app » pour lancer une analyse complète du code. Elle repère des problèmes que la Security View par défaut peut laisser passer.
La vérification de sécurité avant publication, automatisée
- BWorlds passe automatiquement les 12 vérifications avant chaque publication
- Un badge de sécurité public, preuve que votre app a passé les vérifications de base
- Une surveillance continue qui repère les nouvelles failles à chaque mise à jour que vous publiez
Questions fréquentes.
Environ 30 minutes pour une revue manuelle sérieuse. Une analyse automatique comme celle de BWorlds passe ces vérifications en moins de 5 minutes.
Oui. Chaque fois que vous ajoutez des tables, des routes ou des intégrations, repassez les vérifications de sécurité. Du nouveau code généré par l’IA peut ouvrir de nouvelles failles.
Elle couvre le socle. Un grand compte peut aussi exiger la conformité SOC 2, des tests d’intrusion ou une politique de sécurité formalisée. Mais passer cette checklist vous évite les problèmes qui font le plus souvent capoter une vente.
L’absence de policies Row Level Security (RLS) sur les tables Supabase. Quand Lovable crée les tables de la base, la RLS peut ne pas être activée, ou l’être avec des policies trop permissives. Sans RLS correcte, toute personne qui a l’URL de votre projet Supabase et la clé anon peut lire, modifier ou supprimer les données des tables non protégées. C’est la vérification la plus importante de cette liste.
Oui. Les analyses de sécurité automatiques de BWorlds couvrent les 12 points de cette liste, plus d’autres problèmes propres aux apps créées avec l’IA. L’analyse prend moins de 5 minutes et produit un rapport, validé ou à corriger point par point, que vous pouvez partager avec vos clients ou vos partenaires. BWorlds surveille aussi les régressions à chaque mise à jour que vous publiez.
Corrigez-le avant de publier. RLS absente : activez-la sur les tables concernées et ajoutez des policies adaptées. Clés d’API exposées : révoquez-les immédiatement, générez-en de nouvelles et rangez-les dans les Secrets de Lovable. Routes sans authentification : ajoutez une vérification de session. Chaque correction critique prend en général 15 à 30 minutes. Ne publiez jamais en sachant qu’un problème critique reste ouvert.