Reeve Votre appli Lovable est-elle sûre ?
Lovable est-il sûr pour construire ? En général oui. Ce qui décide, c'est un réglage de base de données pris le jour de la création de vos tables.
Les logos sont la propriété de leurs détenteurs respectifs et servent uniquement à indiquer la compatibilité.
En bref
- Une appli Lovable est en général sûre côté code. Ce qui décide si vos données le sont, c'est un réglage Supabase table par table.
- Trouver une clé API dans votre appli est normalement sans gravité. Une clé publiable a sa place ; sb_secret_… ou service_role non.
- Supabase active Row Level Security pour les tables créées dans le Table Editor, mais pas pour celles créées en SQL, et le SQL est la façon dont un builder les crée.
Lovable vous emmène d'une idée à une appli qui marche plus vite que n'importe quoi d'autre, et la partie qu'il prend en charge est justement celle que vous ne voyez jamais : la base de données, les tables, les règles sur qui a le droit de les lire. Quand on vous dit que votre appli Lovable « fuit des données », c'est en général là que se trouve la réponse, et ce n'est pas un endroit que vous pouvez regarder depuis l'éditeur.
Voici ce que guide après guide raconte de travers : le risque n'est presque jamais le code que Lovable a écrit pour vous. C'est un seul réglage de base de données, décidé au moment où une table a été créée, que la plupart des articles sautent ou décrivent à l'envers.
Ce que Lovable construit vraiment, et quelle moitié est publique
Deux moitiés, et une seule est privée.
Voyez cela comme une boutique. Lovable vous construit une devanture : les pages, les boutons, les formulaires, et cette devanture est remise en entier à chaque visiteur. N'importe qui peut la lire. Ce n'est pas un défaut ; un navigateur ne peut pas afficher une page qu'on ne lui a pas donnée. Derrière la devanture se trouve une réserve, votre base Supabase, qui est un bâtiment séparé avec sa propre serrure.
L'erreur qui coûte cher est de supposer que la devanture commande la réserve. Elle ne la commande pas. Retirer un bouton de votre appli, c'est décrocher un panneau, pas fermer une porte. Votre base de données est joignable directement, par internet, par quiconque en connaît l'adresse, et cette adresse est imprimée sur la devanture, puisque c'est ainsi que votre propre appli lui parle.
Une clé dans le code de votre appli Lovable, est-ce un problème ?
En général non. Tout dépend de la clé dont il s'agit, et il en existe deux sortes qui se ressemblent presque trait pour trait.
Une clé publiable dit à quel projet appartient une requête, et rien de plus.
Supabase la nomme sb_publishable_… dans les projets récents et anon dans les
anciens, et elle est conçue pour vivre dans votre appli, là où n'importe qui peut
la lire. Une clé secrète est l'inverse : sb_secret_…, ou service_role
dans les anciens projets. Elle ignore toutes les règles que vous avez posées et
peut lire et écrire chaque ligne de chaque table.
Les deux sont côte à côte dans le tableau de bord Supabase, font la même longueur, et se comportent pareil pendant que vous construisez. Copier la mauvaise tient à un seul clic mal placé, et rien ne casse ensuite : c'est exactement pour cela que ça passe inaperçu. Si vous voulez la version longue de comment les distinguer, nous en avons écrit une.
Ce qui décide si des inconnus peuvent lire vos données
Row Level Security, un interrupteur par table dans Supabase qui décide ligne par ligne qui a le droit de voir quoi. Désactivé, votre clé publiable lit la table entière. Activé et accompagné d'une politique, elle ne lit que les lignes que cette politique autorise.
Vient maintenant la partie qui compte pour une appli Lovable en particulier. Supabase active Row Level Security par défaut pour les tables créées dans le Table Editor du tableau de bord, celui où l'on clique. Les tables créées en exécutant du SQL ne l'obtiennent pas activé et doivent être basculées délibérément.
Exécuter du SQL est la façon dont un builder crée des tables pour vous.
La forme habituelle d'un projet Lovable est donc une poignée de tables que vous avez ajoutées en cliquant, et qui sont protégées, à côté des tables qui ont été générées pour vous, et qui ne le sont peut-être pas. Les deux ont l'air identiques dans l'éditeur. Aucune ne se plaindra. Et activer le réglage n'est toujours pas la ligne d'arrivée, car une table avec Row Level Security activé et une politique qui autorise tout le monde est ouverte d'une manière qui se lit comme fermée.
Comment vérifier votre appli Lovable en une dizaine de minutes
Ouvrez Supabase, puis Authentication → Policies. Parcourez la liste des tables. Tout ce qui est marqué comme ayant Row Level Security désactivé est lisible par quiconque connaît l'adresse de votre projet, qui est publique.
Vérifiez la clé que votre appli embarque. Dans Supabase, allez dans Settings → API. Si la clé utilisée par votre appli est la clé publiable, c'est correct et il n'y a rien à faire. Si une clé secrète a un jour été collée dans votre projet Lovable, renouvelez-la là d'abord : la supprimer de votre code ne ferme pas la porte, car l'ancienne valeur existe toujours dans les copies en cache de votre site.
Regardez vos buckets de stockage. Tout ce qui est marqué public peut être listé et téléchargé par n'importe qui, que votre appli y renvoie ou non.
Puis regardez depuis l'extérieur. Les vérifications ci-dessus vous disent ce qui est réglé ; elles ne vous disent pas ce qu'un inconnu atteint réellement. C'est ce vide que comble notre scan gratuit : il lit votre site en ligne comme le ferait n'importe quel visiteur et vous donne une note en une vingtaine de secondes, sans compte : scanner votre appli.
Que faire
- La devanture est publique par conception. Tout ce que Lovable envoie à un navigateur est lisible par n'importe qui, et aucune dissimulation n'y change rien.
- Une clé publiable dans votre appli est correcte. Une clé secrète (
sb_secret_…ouservice_role) est celle à renouveler aujourd'hui. - Les tables créées dans le Table Editor de Supabase ont Row Level Security activé par défaut. Celles créées en SQL non, et c'est ainsi qu'un builder les crée.
- Activer Row Level Security est la première étape. Une politique qui autorise tout le monde laisse la table ouverte pendant que le tableau de bord la déclare protégée.
- Retirer un écran ou un bouton de votre appli Lovable ne change rien à ce que votre base de données répondra.
La chose la plus rapide et vraiment utile aujourd'hui : ouvrez Authentication → Policies dans Supabase et lisez la liste. Si une table y indique Row Level Security désactivé, commencez par celle-là, et si vous préférez parcourir toute la surface sous forme de liste, la checklist sécurité en 10 minutes couvre le reste.
Ce qui peut réellement mal tourner avec une appli Lovable
Rien de tout cela ne signifie que vous avez fait une erreur. Ce sont les effets secondaires normaux d'une création rapide. Voici ceux qui valent la peine d'être vérifiés :
Une clé secrète expédiée dans le navigateur
Une « clé secrète » est le mot de passe maître d'un service que vous utilisez : votre base de données, un outil d'e-mail, une API d'IA. Elle est censée vivre sur un serveur. Parfois, l'une d'elles se glisse dans le code qui s'exécute dans le navigateur de votre visiteur, où n'importe qui peut la lire, et quelqu'un pourrait s'en servir pour atteindre vos données ou générer des frais en votre nom. La nuance : certaines clés sont censées être publiques (Lovable et Supabase les appellent clés « publishable » ou « anon »), et celles-là ne posent pas de problème. Reeve connaît la différence, donc une clé sûre ne déclenche jamais de fausse alerte.
Votre base de données laissée ouverte (RLS de Supabase désactivé)
Les applis Lovable stockent généralement les données dans Supabase. Supabase possède un interrupteur de sécurité appelé Row Level Security (RLS) qui décide qui a le droit de lire ou de modifier chaque ligne. S'il est désactivé, vos tables peuvent être lisibles, ou modifiables, par quiconque trouve l'adresse. C'est la différence entre « mes données sont à moi » et « ma liste de clients est publique », et c'est le problème le plus fréquent dans les applis vibe-codées.
Un fichier .env ou de configuration exposé
Le fichier .env est l'endroit où un projet garde ses mots de passe et ses clés. De temps en temps, il est publié par erreur en même temps que l'appli. S'il est accessible, c'est un raccourci direct vers tout ce qui est sensible. Reeve vérifie si le vôtre est discrètement accessible.
Stockage de fichiers public
Si votre appli permet aux gens de téléverser des fichiers (photos, PDF), ceux-ci vivent dans des « espaces » (buckets) de stockage. Un espace laissé public signifie que n'importe qui peut parcourir ou télécharger ce qu'il contient, si bien qu'un téléversement destiné à une seule personne peut finir visible par tous. Reeve vérifie si vos espaces sont listables ; il ne télécharge jamais les fichiers de qui que ce soit.
Source maps laissées actives
Une « source map » est un fichier en coulisses qui révèle le code d'origine de votre appli. Pratique pendant le développement, mais si elle part en production, elle donne aux inconnus une copie lisible du fonctionnement de votre appli, ce qui rend chaque porte ci-dessus plus facile à trouver. Pas urgent en soi, mais bon à ranger.
En-têtes de sécurité manquants & points d'accès ouverts
De petits réglages qui indiquent aux navigateurs comment protéger vos visiteurs, plus le fait que les points d'accès de données de votre appli répondent à n'importe qui ou à n'importe quel site. Individuellement mineurs ; ensemble, ils élargissent la faille. Reeve signale ceux qui manquent.
Ce que Reeve est, et ce qu'il n'est pas
Reeve est une vérification gratuite, en lecture seule, depuis l'extérieur, comme un inspecteur qui fait le tour du bâtiment et essaie les portes. C'est rapide et ça repère les erreurs courantes à fort impact. Ce n'est pas un audit de sécurité complet, et une note propre n'est pas une garantie. Elle signifie que les portes évidentes sont fermées.
Lovable est un outil capable, et son équipe ajoute sans cesse des garde-fous de sécurité ; Supabase possède aussi un conseiller intégré qui signale les problèmes de RLS dans son tableau de bord. Les deux sont vraiment utiles. Ce que Reeve ajoute : vous vivez dans Lovable, pas dans la console Supabase, et ces outils parlent le langage des développeurs. Reeve regarde toute votre appli depuis l'extérieur, comme le ferait un inconnu, et vous dit ce qu'il trouve dans des mots exploitables. Et si vous préférez ne pas y penser du tout, nous pouvons la surveiller pour vous.
Vous voulez que ce soit géré, pas seulement vérifié ?
Reeve Care continue de surveiller votre appli, sauvegarde vos données et vous aide à réparer les choses quand elles cassent, pour que vous puissiez continuer à créer au lieu de vous inquiéter.
En savoir plus sur Reeve CareFAQ
Mon appli Lovable est-elle sûre par défaut ?
Lovable vous donne un solide point de départ et améliore sans cesse ses réglages par défaut, mais « sûre par défaut » dépend toujours de la façon dont votre appli est configurée, en particulier des règles de votre base de données Supabase. Le seul moyen de le savoir est de vérifier ce qui est réellement exposé, ce que fait l'analyse gratuite de Reeve en environ 20 secondes.
Une appli Lovable peut-elle laisser fuir mes clés d'API ?
Ça peut arriver, généralement quand une clé qui devrait rester sur un serveur se retrouve dans le code front-end. Mais toutes les clés ne posent pas problème : certaines sont conçues pour être publiques. Reeve lit le code chargé de votre appli, trouve toutes les clés et vous dit lesquelles sont sûres et lesquelles doivent être déplacées.
Qu'est-ce que le RLS de Supabase et pourquoi est-ce important pour mon appli Lovable ?
Le RLS (Row Level Security) est la règle de Supabase qui détermine qui peut voir ou modifier chaque ligne de vos données. S'il est désactivé, vos tables peuvent être ouvertes à tous. Comme la plupart des applis Lovable utilisent Supabase, c'est la chose la plus importante à bien régler, et Reeve la vérifie sans jamais lire vos données réelles.
Analyser mon appli Lovable va-t-il casser quelque chose ou modifier mes données ?
Non. Reeve regarde seulement ce qui est déjà public depuis l'extérieur. Il ne se connecte jamais, ne modifie jamais rien et ne télécharge jamais vos fichiers. En lecture seule, comme vérifier si une porte est verrouillée sans entrer.
Lovable a construit ma base de données. Est-elle configurée en sécurité pour autant ?
Pas automatiquement, et la raison est précise. Supabase active Row Level Security par défaut pour les tables que vous créez en cliquant dans le Table Editor. Les tables créées en exécutant du SQL ne l'obtiennent pas, et le SQL est la façon dont un builder crée des tables pour vous. Les tables que vous avez faites à la main sont donc en général protégées, et celles que Lovable a faites peut-être pas.
Quelles tables ont Row Level Security activé ?
Ouvrez votre projet Supabase, allez dans Authentication puis Policies. Chaque table de votre schéma public y est listée avec l'état de RLS. Tout ce qui apparaît comme désactivé est lisible par quiconque possède l'adresse de votre projet et votre clé publiable, deux choses qui se trouvent dans votre appli.
J'ai trouvé une clé dans mon appli Lovable. Comment savoir si elle compte ?
Lisez de quel type elle est. Une clé publiable (nommée sb_publishable_ dans les projets Supabase récents, ou anon dans les anciens) a sa place dans le navigateur et n'est pas une fuite. Une clé secrète, sb_secret_ ou l'ancienne service_role, ignore toutes les règles que vous posez et ne doit jamais atteindre un navigateur. Si vous trouvez celle-là, renouvelez-la dans le tableau de bord Supabase avant toute autre chose.