Sécuriser une application Lovable : 12 contrôles
Publié le 20.10.2026 · 7 min de lecture
Sommaire
Une application Lovable est sûre quand chaque table de sa base filtre ce que chacun peut lire et modifier, quand aucune clé secrète n'atteint le navigateur et quand les opérations sensibles passent par le serveur. Ces 12 contrôles, à faire dans l'ordre, couvrent l'essentiel des fuites constatées sur les applications construites avec l'IA.
Pourquoi les applications fuient
Une application Lovable parle à sa base Supabase avec une clé publique, visible dans le navigateur. C'est normal : cette clé est faite pour être vue. Ce qui protège les données, ce sont les règles d'accès appliquées par la base à chaque requête. Quand elles manquent, quiconque récupère la clé peut lire la table. Un scan publié de 183 applications publiques a relevé au moins un problème de sécurité sur 181 d'entre elles.
Les 12 contrôles
1. Règles d'accès actives sur toutes les tables
Chaque table doit avoir la sécurité au niveau des lignes (RLS) activée et des règles par opération. Demandez à Lovable, en mode Plan, la liste des tables avec l'état de leurs règles, puis vérifiez dans le tableau de bord Supabase.
2. Tests par rôle
Créez au moins deux comptes par rôle et vérifiez qu'un utilisateur ne voit ni ne modifie les données d'un autre, y compris en recopiant l'adresse d'une page qui ne lui appartient pas.
3. Aucune clé secrète côté navigateur
La clé de service de Supabase et les clés secrètes de Stripe ou de votre service de courriel ne doivent exister que dans les secrets des fonctions serveur. Cherchez leurs préfixes dans le code, dans GitHub et dans les outils de développement du navigateur.
4. Opérations sensibles côté serveur
Prix, droits, envois groupés, appels à des services payants : ils passent par une fonction serveur qui vérifie l'identité et les droits de l'appelant.
5. Webhooks de paiement vérifiés
L'accès payant s'ouvre uniquement quand Stripe le confirme par un webhook signé, jamais parce que l'utilisateur est arrivé sur la page de remerciement.
6. Authentification complète
Confirmation de l'adresse active, redirections limitées à vos adresses, comptes de test supprimés avant la production, inscription libre désactivée si l'application est sur invitation.
7. Fichiers privés et liens qui expirent
Les documents des utilisateurs vont dans un espace de stockage privé, avec des règles d'accès et des liens signés à durée limitée.
8. Validation en base
Les contraintes (champs obligatoires, longueurs, listes de valeurs) sont posées dans la base, pas seulement dans le formulaire.
9. Protection des données
Ne collectez que le nécessaire, fixez des durées de conservation et publiez une politique de confidentialité conforme à la nLPD, et au RGPD si vous visez l'Union européenne.
10. Sauvegarde testée
Vérifiez ce que couvre votre offre Supabase, sauvegardez aussi les fichiers stockés, et testez une restauration sur un projet de test.
11. Journaux et alertes
Sachez où lire les journaux de l'API, de l'authentification et des fonctions, et vérifiez-les après chaque mise en ligne.
12. Contrôles automatiques traités
Lancez le scan de sécurité de Lovable et le conseiller de sécurité de Supabase, traitez chaque alerte critique et relancez jusqu'à zéro. Vérifiez enfin le HTTPS de votre domaine et l'authentification de vos courriels (SPF, DKIM, DMARC).
La checklist en un coup d'œil
| N° | Contrôle | Test minimal |
|---|---|---|
| 1 | RLS active partout | Liste des tables et de leurs règles |
| 2 | Tests par rôle | Deux comptes par rôle, accès croisés refusés |
| 3 | Aucune clé secrète côté navigateur | Recherche des préfixes dans le code, GitHub et le navigateur |
| 4 | Opérations sensibles côté serveur | Aucun prix ni droit calculé dans l'interface |
| 5 | Webhooks vérifiés | Un appel sans signature est refusé |
| 6 | Authentification complète | Redirections limitées, comptes de test supprimés |
| 7 | Fichiers privés | Un lien expiré ne s'ouvre plus |
| 8 | Validation en base | Une valeur interdite est refusée même hors formulaire |
| 9 | Protection des données | Politique publiée, durées de conservation fixées |
| 10 | Sauvegarde testée | Restauration réussie sur un projet de test |
| 11 | Journaux | Vous savez où lire les erreurs |
| 12 | Contrôles automatiques | Zéro alerte critique, HTTPS et courriels authentifiés |
Exemple de matrice de tests
Pour une application où des clients déposent des documents et où des collaborateurs les traitent, la matrice tient en une dizaine de lignes. Lecture des dossiers d'un client A : oui pour le client A, le collaborateur qui le suit et l'administrateur ; non pour le client B, un autre collaborateur et le visiteur anonyme. Suppression d'un dossier : non pour tous, puisqu'un dossier s'archive. Les cases « non » sont les plus importantes : un test qui ne vérifie que ce qui doit marcher ne prouve rien sur la sécurité.
Ce que les outils automatiques ne voient pas
Les scanners repèrent une table sans règles ou une fonction trop exposée. Ils ne savent pas qu'un collaborateur ne doit voir que ses propres clients. Une règle peut être techniquement correcte et fausse pour votre métier. D'où l'intérêt des tests par rôle et d'une relecture humaine avant la mise en production.
Un exemple vécu : en construisant notre propre plateforme, le conseiller de Supabase a signalé qu'une fonction de vérification des rôles était appelable par tout utilisateur connecté. Corriger a pris une migration ; ne pas le savoir aurait laissé une fuite d'information.
Que faire en cas d'alerte critique
- Ne publiez pas, ou retirez la publication si l'application est en ligne.
- Corrigez par une migration, jamais en désactivant une règle pour « faire marcher » l'affichage.
- Si une clé secrète a été exposée, régénérez-la immédiatement chez le fournisseur.
- Relancez les contrôles et rejouez vos tests par rôle.
Questions fréquentes
Lovable est-il sûr ?
L'outil fournit des contrôles de sécurité utiles. La sécurité de votre application dépend surtout de vos règles d'accès, de vos secrets et de vos tests.
La clé publique de Supabase est-elle un problème ?
Non, elle est faite pour être visible. Le problème est une table sans règles d'accès, que cette clé permet alors de lire.
Faut-il faire appel à un auditeur externe ?
Pour une application qui traite des données personnelles de clients réels, un second regard est recommandé avant la première mise en production, puis à chaque évolution importante. Il ne remplace pas vos propres tests : il vérifie ce que vous n'avez pas pensé à tester, en particulier les règles métier.
Que vérifier avant chaque nouvelle publication ?
Au minimum : relancer les deux contrôles automatiques, rejouer les cases « non » de votre matrice de tests, et rechercher les clés secrètes si du code serveur a été modifié. Dix minutes suffisent quand la matrice est à jour.
Combien de temps prennent ces contrôles ?
Comptez environ deux heures pour une petite application, puis quelques minutes avant chaque nouvelle publication.
Sources : preuve.ai, scan de 183 applications, consulté le 19.10.2026 ; documentation de Supabase et de Lovable.