Ton app vibe-codée expose peut-être tes données

Hier, j'ai trouvé une clé sur la porte d'entrée d'un site public, à la vue de tout le monde. J'aurais pu aspirer sa base de données utilisateurs. J'ai prévenu le fondateur à la place. Presque 24 heures après, la clé était toujours là.

Ce n'est pas un cas isolé. Sur la dizaine d'apps que j'ai scannées un matin, au hasard des pubs qui passaient sur X et LinkedIn : 5 laissaient leur code source accessible, 1 exposait la clé qui donne accès à toute sa base, 2 seulement étaient propres. Si tu as vibe-codé ton app avec Lovable, Bolt, v0 ou Replit, il y a de bonnes chances que tu sois dans le premier groupe sans le savoir. Voilà ce qui fuit, pourquoi ça compte côté RGPD, et comment le vérifier en deux minutes.

« Vibe-codé », ça veut dire quoi pour ta sécurité

Tu as décrit ton app à une IA, elle a écrit le code, tu as déployé. C'est génial pour la vitesse. Le problème, c'est que l'IA optimise pour « ça marche », pas pour « c'est fermé ». Elle branche ta base de données, elle pose tes clés, elle te sert une app qui tourne. Elle ne te dit pas que la clé qu'elle vient de coller est visible par n'importe quel visiteur, ni que ta base répond à qui la demande.

Toi tu vois une app qui fonctionne. Un curieux, lui, ouvre les outils de développeur de son navigateur et voit autre chose : tes clés, tes appels réseau, parfois ton code entier. Rien à pirater. Tout est déjà servi, en clair, dans la page.

Les quatre portes qu'une app vibe-codée laisse souvent ouvertes

1. Ta base de données lisible sans mot de passe

C'est la faille numéro un, et de loin. La plupart des apps vibe-codées utilisent Supabase pour stocker les données. Supabase a un verrou qui s'appelle le RLS (Row Level Security), la sécurité au niveau des lignes. Tant qu'il est désactivé, ta clé publique suffit à lire toutes les tables : emails, commandes, messages, tout.

Et cette clé publique, elle est forcément dans ton app, c'est normal, elle sert à l'app pour parler à la base. Le souci n'est pas la clé. Le souci, c'est que la porte derrière (le RLS) est restée grande ouverte. Environ 70 % des apps Lovable analysées avaient le RLS désactivé, et 1 sur 10 exposait carrément des tables en public. Traduction : n'importe qui recopie ta base chez lui en une requête. J'ai détaillé cette faille dans RLS désactivé : pourquoi ta base est lisible.

2. Tes vraies clés secrètes laissées dans le code

Il y a la clé publique (normale, faite pour être vue), et il y a les clés secrètes, qui ne doivent JAMAIS finir côté navigateur. La clé service_role de Supabase, une clé Stripe sk_live, une clé OpenAI. Quand l'IA les colle en dur dans le code du front pour « que ça marche vite », elles se retrouvent dans le JavaScript téléchargé par chaque visiteur.

Une clé service_role exposée, c'est simple : tu viens de poser la clé de ta maison sur le paillasson avec un panneau « bienvenue ». Elle ignore le RLS, elle lit et écrit tout. Une clé Stripe secrète, c'est ta caisse. Ça se trouve en quelques secondes, il suffit de savoir où regarder.

3. Ton code source rendu public

Beaucoup d'apps servent leurs « source maps » en production. Ce sont des fichiers qui reconstruisent ton code d'origine à partir du JavaScript compilé. Pratique pour déboguer, catastrophique en public : un curieux télécharge le .map, et il lit la logique de ton app comme si tu lui avais donné ton dépôt. Il repère alors les vraies failles plus vite, et parfois d'autres clés oubliées dans un commentaire.

C'est ce que je retrouve le plus souvent sur le terrain. 5 des apps de mon échantillon du matin servaient leur code de cette façon.

4. Les protections de base absentes

Les en-têtes de sécurité (CSP, HSTS, et compagnie) sont les serrures secondaires de ton app. Seuls, ils ne fuitent pas tes données, mais leur absence ouvre la porte au détournement de session, à l'injection de code, à l'affichage de ton app dans une fausse page. La plupart des apps vibe-codées n'en posent aucun, parce que personne ne leur a dit de le faire.

C'est le niveau le moins grave des quatre. Ça reste un signal que ton app est partie en prod sans que personne n'ait vérifié les fondamentaux.

Pourquoi c'est un problème RGPD, pas juste technique

Voilà l'angle que la plupart des développeurs zappent, et celui qui devrait t'inquiéter le plus si tu as des vrais utilisateurs.

Le jour où ta base est lisible et qu'elle contient des données personnelles (un email suffit), tu n'as pas juste un bug. Tu as une violation de données au sens du RGPD. La loi te demande alors de notifier la CNIL sous 72 heures (article 33), et selon les cas d'informer les personnes concernées. Une base d'emails ouverte, ce n'est pas « un truc technique à corriger un jour », c'est une obligation légale qui court dès que quelqu'un tombe dessus.

L'amende maximale théorique va jusqu'à 4 % du chiffre d'affaires annuel. En vrai, une petite app ne prend pas 20 millions d'euros. Mais la CNIL sanctionne aussi des petites structures, et surtout : une fuite qui se sait, c'est la confiance de tes premiers utilisateurs qui part. Pour un produit qui démarre, c'est souvent pire qu'une amende.

C'est pour ça que je cadre tout en RGPD et pas en jargon cyber. « CVSS 9.1 » ne parle à personne. « Ta base d'emails est lisible, et légalement tu dois prévenir la CNIL si ça arrive » parle à tout le monde.

Comment savoir si ton app est concernée

Deux façons. La gratuite et manuelle, et la rapide.

À la main. Ouvre ton app dans Chrome, fais un clic droit puis « Inspecter », et va dans l'onglet Réseau. Recharge la page et regarde les appels qui partent vers supabase.co. Si une table te renvoie des lignes de données alors que tu n'es pas connecté, ton RLS est désactivé sur cette table. C'est déjà un signal fort, et tu peux suivre la manip complète en deux minutes. Pour les clés, cherche dans l'onglet Sources les mots service_role, sk_live, sk-. C'est faisable, mais il faut savoir où creuser et lire ce que tu vois.

Plus vite. Colmate lit tout ce que ton app expose déjà publiquement et te sort la liste en trente secondes, classée par gravité et traduite en risque concret, avec un fichier de correction prêt à coller dans ton outil IA. Pour la base, il ne teste rien : il repère que tu utilises Supabase avec une clé publique exposée côté client, le profil exact de la faille RLS, et te le signale comme à vérifier en priorité. En lecture seule, sans accès à ton code et sans jamais toucher à tes données. Je n'ai pas besoin de ton dépôt GitHub, juste de l'URL publique, celle que n'importe quel visiteur voit déjà.

Scanne ton app maintenant, c'est gratuit. Tu verras tout de suite si tu es dans le groupe des 2 sur 10 qui sont propres, ou dans l'autre.

FAQ

Est-ce que vous avez besoin de mon code pour scanner mon app ?

Non. Colmate analyse uniquement ce que ton app expose déjà publiquement, comme le ferait n'importe quel visiteur. Tu ne donnes pas accès à ton dépôt GitHub ni à ton compte. C'est le principe : je regarde la porte depuis la rue, je n'entre pas.

Ma clé Supabase « anon » est visible dans le code, c'est grave ?

Pas en soi. La clé anon (ou publishable) est faite pour être publique, elle sert à ton app pour parler à la base. Ce qui est grave, c'est si le RLS est désactivé derrière : là, cette clé publique suffit à lire toute ta base. La vraie question n'est pas « ma clé est-elle visible », c'est « ma base est-elle verrouillée ».

Comment savoir si le RLS est activé sur ma base Supabase ?

Le plus simple : ouvre les outils de développeur de ton navigateur, onglet Réseau, et regarde si une requête vers ta base te renvoie des lignes sans que tu sois connecté. Si oui, le RLS est désactivé sur cette table. Colmate, lui, ne teste jamais ta base : il repère que ton app utilise Supabase avec une clé publique exposée (le profil de cette faille) et te signale que c'est à vérifier en priorité, avec la procédure ci-dessus et les policies à coller.

Est-ce légal de scanner ma propre app ?

Oui. Tu scannes ton application, ou une application que tu es autorisé à tester. On te le demande avant chaque scan (case à cocher), et on reste en lecture seule sur des informations déjà publiques. On ne sonde jamais ta base ni celle d'un tiers, on déduit à partir de ce que l'app sert d'elle-même.

Le réflexe à prendre avant de lancer

Tu ne mettrais pas en ligne un site sans regarder à quoi il ressemble. C'est pareil pour ce qu'il expose. Avant de partager ton app, avant de la lancer sur les réseaux, prends deux minutes pour vérifier que tu n'as pas laissé la clé sur la porte. La checklist complète avant déploiement te donne les six points à passer.

Lance un scan gratuit de ton app. Si quelque chose fuit, tu le sauras, et tu repartiras avec de quoi le colmater. D'autres notes de terrain sont sur le blog.