Une application créée avec Lovable, Bolt ou Base44 parle directement à sa base de données depuis le navigateur de l’utilisateur. C’est ce qui rend ces outils si rapides : aucun serveur intermédiaire à écrire, l’écran interroge les données et les affiche. C’est aussi ce qui rend l’application dangereuse quand une règle précise n’a pas été posée.

Cette règle porte un nom technique, la sécurité au niveau des lignes. Elle décide, pour chaque enregistrement de chaque table, qui a le droit de le lire et de le modifier. Sans elle, la base répond à tout le monde.

Ce que voit réellement le navigateur

Votre application embarque une clé publique qui lui permet de joindre la base. Cette clé est publique par conception : elle est visible dans le code de la page, et la documentation de Supabase le dit explicitement. Elle est conçue pour être publique, à une condition, que les politiques d’accès soient en place derrière.

Quand elles ne le sont pas, n’importe qui peut reprendre cette clé et interroger la base directement, sans passer par vos écrans. Aucun piratage au sens où on l’imagine : la base répond parce qu’on lui a demandé poliment et que rien ne lui a dit de refuser.

Le résultat est brutal. Une table de clients se télécharge entièrement. Une table de commandes aussi, avec les montants. Une table d’utilisateurs livre les adresses de messagerie de toute votre base.

Ce n’est pas une hypothèse

En avril 2025, une faille référencée sous le numéro CVE-2025-48757 a mis en évidence exactement ce mécanisme sur des applications produites avec Lovable. Le défaut : des politiques de sécurité insuffisantes permettant à un visiteur non authentifié de lire et d’écrire dans des tables qui auraient dû être fermées. La gravité a été évaluée à 9,3 sur une échelle de 10, et plus de 170 applications étaient concernées.

Ce n’est pas un incident isolé dans le paysage. Le contrôle d’accès défaillant occupe la première place du classement des risques applicatifs établi par l’OWASP, avec plus de 318 000 occurrences relevées dans les données contribuées. Autrement dit, c’est le défaut le plus répandu de tout le développement web, et les outils de génération le reproduisent fidèlement.

Une étude publiée par Veracode en 2025 donne l’ordre de grandeur du phénomène : sur 80 tâches de développement soumises à plus d’une centaine de modèles, le code produit comportait une vulnérabilité dans 45 % des cas quand un choix existait entre une méthode sûre et une méthode risquée.

Quatre vérifications que vous pouvez faire vous-même

Le test des deux comptes. Créez deux comptes d’essai avec des données différentes. Connectez-vous au premier, ouvrez une fiche, relevez l’adresse affichée dans la barre du navigateur. Déconnectez-vous, connectez-vous au second, collez cette adresse. Si la fiche du premier apparaît, la règle manque.

Le test de la navigation privée. Copiez l’adresse d’un document ou d’une image déposée par un utilisateur, puis ouvrez-la dans une fenêtre de navigation privée où vous n’êtes connecté à rien. Si elle s’affiche, votre espace de stockage est public.

Le tableau de bord de la base. Dans Supabase, la liste des tables signale celles qui n’ont aucune politique active. Un projet généré rapidement en compte souvent plusieurs, et personne ne les a jamais regardées.

Les rôles. Si votre application distingue un administrateur d’un utilisateur simple uniquement en masquant des boutons à l’écran, cette distinction ne protège rien. Un bouton caché reste accessible à qui sait le demander.

Pourquoi cela arrive presque toujours

Ces outils font ce qu’on leur demande, et personne ne leur demande explicitement d’écrire des politiques d’accès. Créer une table est une instruction naturelle. Écrire, pour cette table, la règle qui limite chaque utilisateur à ses propres lignes ne l’est pas, surtout quand on ne sait pas que cette règle existe.

Supabase active d’ailleurs un comportement prudent : quand la sécurité au niveau des lignes est activée sans aucune politique, la table devient inaccessible. Le piège vient de l’inverse, une table créée sans que la protection soit activée du tout, qui reste alors ouverte par défaut.

Comment se déroule la correction

La reprise commence par un inventaire : chaque table, chaque type de donnée, et la liste de qui doit y accéder et dans quelles conditions. Cet inventaire s’écrit en français, pas en jargon, parce que c’est vous qui devez valider les règles. Un commercial voit-il les dossiers de ses collègues ? Un client voit-il l’historique de ses commandes uniquement, ou aussi ses devis refusés ?

Les politiques sont ensuite écrites table par table, du côté de la base et non de l’écran. Le contrôle ne dépend alors plus de la façon dont la demande est formulée.

La dernière étape est la vérification. On rejoue les accès avec des comptes de test pour confirmer que ce qui doit être refusé l’est effectivement. Une correction qu’on ne vérifie pas ne vaut rien : c’est justement l’absence de vérification qui a créé la situation initiale.

Ce que vous devez à vos clients si les données ont circulé

Une exposition de données personnelles n’est pas seulement un incident technique. Dès lors qu’elle présente un risque pour les personnes concernées, elle doit être notifiée à la CNIL dans les 72 heures suivant le moment où vous en avez pris connaissance, et la procédure est décrite sur son site. Le délai court à partir de votre prise de connaissance, pas de la date de la fuite.

Même quand la notification n’est pas requise, l’incident doit figurer dans un registre interne des violations, et cette obligation ne souffre pas d’exception.

C’est une raison de plus de faire le tour de la question avant d’y être contraint : la vérification prend quelques heures, la déclaration d’une fuite avérée occupe plusieurs jours et se fait sous pression.

Ce que nous faisons

Nous lisons le code de votre application et nous établissons la liste de ce qui est réellement exposé aujourd’hui, avec ce que chaque point implique pour votre activité. Ce document est en français, lisible sans compétence technique, et il vous appartient.

Vous décidez ensuite du périmètre de la correction et vous recevez un devis à prix fixe. Nous reprenons les règles d’accès une par une, nous les éprouvons, et nous vous montrons comment refaire ces vérifications vous-même par la suite.