18 août 2026

Sécurité Lovable : les failles les plus fréquentes (et comment les corriger)

Lovable génère une app complète — frontend et backend Supabase inclus — à partir d'un prompt. C'est justement ce qui rend le risque particulier : le backend existe, avec de vraies tables et une vraie base de données accessible depuis n'importe où, avant même que tu aies pensé à qui devrait pouvoir y accéder.

Row Level Security, l'angle mort le plus fréquent

Lovable connecte le projet à Supabase et crée les tables que le prompt implique (utilisateurs, commandes, messages...). Row Level Security (RLS) — le mécanisme qui décide qui a le droit de lire ou d'écrire quelle ligne — n'est pas toujours configuré correctement du premier coup : soit il reste désactivé sur certaines tables, soit une policy générée par l'IA utilise USING (true) pour "faire marcher" une fonctionnalité rapidement, ce qui revient au même que pas de policy du tout.

La clé anon de Supabase est publique par design — elle est dans le JavaScript envoyé à chaque visiteur. Sans RLS correctement écrit, n'importe qui peut l'utiliser pour interroger directement l'API REST de Supabase et lire (ou écrire) le contenu brut des tables, en contournant entièrement l'interface que Lovable a générée :

curl "https://<projet>.supabase.co/rest/v1/users?select=*" \
  -H "apikey: <clé anon trouvée dans le JS>"

Si cette requête renvoie des lignes que le visiteur n'aurait jamais dû voir sans être connecté, RLS n'est pas correctement configuré sur cette table.

Le lien de preview est public par défaut

Le lien de partage que Lovable génère pour prévisualiser une app en cours de construction n'est protégé par aucune authentification — quiconque le devine ou le récupère (lien partagé dans un canal Slack, un ticket, un email) accède à l'app exactement comme un utilisateur normal, y compris aux mêmes failles RLS que ci-dessus si le projet Supabase associé n'est pas encore verrouillé. Un projet en phase de prototypage, avec des vraies données de test qui ressemblent à des vraies données de prod, mérite le même niveau de vigilance qu'un site déjà en ligne.

Le correctif

Active RLS sur chaque table dès sa création, avec une policy qui restreint réellement l'accès à son propriétaire :

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY "users_read_own_orders" ON orders
  FOR SELECT
  TO authenticated
  USING (auth.uid() = user_id);

Si tu demandes à Lovable d'ajouter une fonctionnalité qui touche à une nouvelle table, précise explicitement dans le prompt qui doit pouvoir y accéder ("seul l'utilisateur propriétaire peut lire/modifier sa commande") plutôt que de laisser l'IA deviner — c'est la différence entre une policy correcte et un USING (true) qui fait taire l'erreur sans corriger le problème. Vérifie aussi que la clé service_role (celle qui contourne RLS entièrement) n'apparaît nulle part dans le code exécuté côté client.

Guide complet des pièges RLS les plus fréquents : RLS Supabase désactivé ou mal configuré.

Une app Lovable en ligne (ou en preview) ? Scanne-la pour vérifier si tes tables Supabase sont accessibles sans authentification.