Connexion Premium

Vibe coding : des milliers de web apps exposent des données sensibles en ligne

Une URL, et tout devient accessible

Vibe coding : des milliers de web apps exposent des données sensibles en ligne

Illustration : Flock

Plus besoin de connaissances en HTML ou en JavaScript pour développer des web apps : il suffit de la décrire à une des plateformes de vibe coding qui se partagent un marché florissant. Mais la sécurité est le parent pauvre de cette pratique.

Les apps générées par IA publiées sur internet sont souvent peu sécurisées. Red Access, une entreprise spécialisée dans la sécurité dans le nuage, et son cofondateur Dor Zvi ont analysé des milliers de web apps créées avec des outils comme Lovable, Replit, Base44 et Netlify. Le résultat fait froid dans le dos : plus de 5 000 d’entre elles ne présentent aucune authentification ni véritable sécurité.

La simplicité c’est bien, la sécurité c’est mieux

Il suffit de trouver l’URL du site web pour accéder aux données de ces applications. D’autres n’opposaient comme résistance que des barrières faciles à franchir, comme l’obligation de se connecter avec une adresse email. Environ 40 % de ces web apps exposent des données sensibles, des documents confidentiels ou des historiques de conversation entre clients et chatbots. Dor Zvi tire la sonnette d’alarme chez Wired :

« Des organisations se retrouvent à divulguer des données privées via des applications créées avec le vibe coding. C’est l’un des plus grands cas de fuite où des personnes exposent des informations d’entreprise ou d’autres données sensibles à n’importe qui dans le monde. »

Parmi les trouvailles de l’équipe de Red Access : des plannings d’hôpitaux avec des informations personnelles sur des médecins, les achats publicitaires d’une entreprise, une présentation de lancement commercial, les registres de cargaisons d’une société de transport… Dans certains cas, Dor Zvi aurait pu obtenir les privilèges admin de certaines de ces apps en ligne — et même supprimer des comptes administrateurs.

Les plateformes de vibe coding permettent aux utilisateurs d’héberger leurs web apps directement sur leurs propres domaines. Pour mettre la main dessus, les chercheurs ont simplement utilisé Google ou Bing. Ils ont également trouvé plusieurs sites d’hameçonnage reproduisant ceux de grandes entreprises, créés et hébergés chez Lovable.

« Certains utilisateurs ont publié sur le web des applications qui auraient dû rester privées », explique Amjad Masad, le directeur général de Replit. « Qu’une application publique soit accessible sur internet est donc un comportement attendu. Les paramètres de confidentialité peuvent être modifiés à tout moment en un clic. » Rappelant l’existence d’outils de sécurité sur sa plateforme, le dirigeant s’engage à basculer les applications en mode privé et à informer les utilisateurs, si Red Access décide de lui transmettre une liste de ces derniers.

Masad reproche au passage le délai très court donné par la société de cybersécurité : « moins de 24 heures » avant de rendre l’affaire publique, ce qui n’a guère laissé de temps à Replit pour s’organiser. Le 6 mai, Replit annonçait que tous les utilisateurs du service, gratuit comme payant, peuvent publier leurs apps en mode privé. Une fonction qui était réservée auparavant aux clients Pro et Enterprise.

La responsabilité des plateformes

Chez Lovable, on indique également que les utilisateurs ont des outils de sécurité à leur disposition, « mais la manière dont une application est configurée relève au final de la responsabilité de son créateur ». Même discours du côté de Base44 : « Désactiver ces contrôles [de sécurité] est une action volontaire et simple, que n’importe quel utilisateur peut effectuer ». Une web app rendue publique est « un choix de configuration de l’utilisateur, et pas une faille de la plateforme ».

Base44 rappelle aussi qu’il est très simple de générer des données ressemblant à des vraies. Malgré tout, le risque d’exposer des informations confidentielles via des web apps vibe-codées reste réel. Ces outils sont utilisés par des utilisateurs n’ayant pas nécessairement le bagage technique suffisant pour sécuriser leurs données en ligne. 

« N’importe qui dans une entreprise peut générer une application à tout moment, sans passer par un cycle de développement standard ni par le moindre contrôle de sécurité », prévient Dor Zvi. Les plateformes ont une responsabilité ici, celle de mettre en place des garde-fous pour éviter un tsunami potentiel de fuites de données.

Commentaires (34)

votre avatar
En même temps, faut être sacrément inconscient pour mettre en ligne une app vicodé....
J'ai pu en faire, mais ça restera sur mon poste, ou au pire en interne.
votre avatar
:troll:
Mais kes tu raconte ! Faut pas empêcher l'innovation là !
La disruptive attitude, tout ça.
votre avatar
vicodé
Ah ça va, je préfère nano. :D

Mais même avis, ce que sortent les LLM ne sont pas assez bons pour partir direct en prod. C'est OK pour des extraits, mais à prendre avec des pincettes comme ce que tu trouves dans une réponse sur StackOverflow.

(Edit: j'ai envoyé trop tôt)
votre avatar
La blague est valide!
votre avatar
À la limite, si le bouzin est assez performant, le lambda vibecode son app pour un proto, et demande à un dev pro de reproduire ce fonctionnement/apparence à l'identique. Là ça se tient.
Et si le LLM est pas dégueulasse, envisager éventuellement un jour, la reprise/peaufinage de code.
votre avatar
À la limite, si le bouzin est assez performant, le lambda vibecode son app pour un proto, et demande à un dev pro de reproduire ce fonctionnement/apparence à l'identique. Là ça se tient.
Bof, c'est super dévalorisant et ça laisse considérer que le dev n'est qu'un pisseur de code sans valeur ajoutée.

C'est aussi dévalorisant que de demander à un artiste de reproduire une CRAP.
votre avatar
Sauf que l'on vit dans un monde où les gens vendent des compétences contre de l'argent à un client. Si le client à cette demande, je vois mal un développeur ayant besoin de boulot, faire la fine bouche. Ce n'est pas si différent de l'établissement d'un cahier des charges.
Après si t'es un dieu du codage qui fait payer des sommes folles ses compétences, c'est autre chose, mais ça ciblera surtout ceux qui ont de gros moyens, pas les gens lambda.

Évidemment, dans un contexte communautaire de développement de projet libre ou d'un pseudo-freeware, c'est totalement différent...
votre avatar
Sauf que l'on vit dans un monde où les gens vendent des compétences contre de l'argent à un client.
Je suis freelance, donc un peu au courant :p

Mais bon, si l'idée c'est aussi de vendre un monde où t'es juste bon à réécrire ce qu'un LLM a pondu après des demandes de personnes n'y connaissant rien, perso je suis pas fan.

Accessoirement, pondre le logiciel avec un LLM pour ensuite demander à un dev de le réécrire, pour moi c'est faire le taff en double. Combien de temps aura-t-il fallu pour avoir un prototype fonctionnel de la part d'une personne non initiée avec un LLM ?

Le plus important dans un projet logiciel, à mes yeux, c'est de savoir ce que le logiciel va faire et comment. Une expression de besoin, si je devais dire des gros mots. Le client aurait donc plus intérêt à rédiger le cahier des charges, le lotir pour définir le MVP et les itérations suivantes, qu'à faire du dev Frankenstein avec un LLM (qu'il aura payé) pour ensuite payer une prestation pour tout refaire.

Source : 15 ans à subir des projets applicatifs dont la spec se résumait à un post-it et filé à un stagiaire livré à lui-même. Ceux qui ont écrit le post-it sont partis, et on se retrouve avec un logiciel dont le métier pense qu'il fait un truc, mais quand le nouveau dev ouvre le capot ça fait autre chose. Et personne ne sait ce que devrait réellement faire le produit.

Mon opinion : si c'est pas votre métier, ne le faites pas.

Quand on voit que même leur métier, les entreprises ne le maîtrisent pas...
votre avatar
Merci pour ce point de vue très intéressant et le partage de ton expérience. 👌
votre avatar
On a envisagé le LLM pour maquetter des applis / IHM en mode Agile : tu brainstromes avec tes key-users, tu ponds un prompt, le LLM génère l'IHM, et tu itères.

Perso j'ai pas eu l'occasion de tester, et je ne suis pas certain du gain : maquetter une IHM non fonctionnel ça prend pas des plombes non plus; Le sketchbook en papier / paperboard ça marche pas mal aussi (et ça aide à faire abstraction des détails genre couleurs, polices, icônes...).

A voir le temps que moulinerait le LLM + le temps de générer le bon prompt, et pas sûr non plus du taux de reuse de code généré en LLM. (l'IHM à la main c'est réutilisable...)

Après je pense que c'est le dev qui doit prompter / ajuster, il faut arrêter de croire en la magie d'une IA "consultant" voire autonome.
votre avatar
Bof, c'est super dévalorisant et ça laisse considérer que le dev n'est qu'un pisseur de code sans valeur ajoutée.
C'est déjà le cas depuis quelques années, même sans l'IA. D'où toutes ces klûteraa de scrum qui a dégénéré en une surcouche qui ajoute la vaseline les cérémonies pour s'assurer que tout développeur est remplaçable dans la journée sans coût ajouté.
votre avatar
Oui, les métiers comme les devs et autres "petites mains" techniques étaient déjà sous valorisées en entreprise. Donc évitons d'enfoncer le clou en leur disant qu'ils sont juste là pour "recoder" ce qui sort de l'anus du LLM.
votre avatar
votre avatar
Les plateformes se dédouanent bien vite!
Ce sont elles qui mettent à disposition ces outils et en promeuvent la simplicité de la toute puissance.
Il leur manque un peu de configuration: à minima un pattern de configuration, un RAG pour que leur IA soit personnalisé à leur service, des skills préconfigurés pour de la review, ou juste un analyseur statique avant la livraison.
J'espère qu'elles vont revoir un peu leur marketing à paillettes IA.
votre avatar
Comment savoir si une appli est vibecodée ou pas ? Faut-il écarter toute appli sortie récemment ?
Quitter à bien faire sur toute la chaîne, je suppose qu'elles n'ont même pas de mentions légales... Ou de politique de protection des données perso ?
votre avatar
Sur le principe, la plupart des services considèrent qu'un projet dev par LLM t'appartiens, c'est une vraie oeuvre de l'esprit même vibecodé, et les lois vont dans ce sens aussi.
Pour les œuvres dites artistiques, typiquement la musique générée & cie, les USA considèrent que ça ne t'appartient pas et que tu n'as aucun droit dessus, par exemple.
votre avatar
Je voulais dire du point de vue utilisateur : si je m'apprête à créer un compte sur une nouvelle appli, je voudrais savoir si elle a été vibecodée, ce qui me ferait réfléchir avant de créer un compte.
votre avatar
À code égal, je dirais, pourquoi ce dogmatisme ? Le code pondu avec llm ou son assistance, c'est devenu le ma absolu ?
votre avatar
Pourquoi "à code égal" ? L'actu dit justement que ce n'est pas la même qualité niveau sécurité.
votre avatar
Tu mentionnais spécifiquement "nouvelle appli". J'ai donc répondu dans ce cadre.
Et le code égal est bien un si et un quand, pas une comparaison avec la situation actuelle.
Les progrès ces dernières années ont été dingues en matières de LLM pour le développement, si demain un modèle fait aussi bien, voir mieux qu'un dev expérimenté, tu le rejetteras pour autant par principe ?
Et même sans ça, un dev experimenté qui se fait assister par de l'IA pour avancer plus rapidement tout en faisant la relecture nécessaire ?

Entre nous, sur tous les sujets, j'ai un peu de mal, avec le dogmatisme, et l'IA ne fait pas exception...
votre avatar
Je ne rejette rien (obligation de l'utiliser au boulot, et quelques prompts perso), mais j'interroge toujours.
L'actu dit qu'une appli vibecodée a plus de risque d'exposer des données, donc ceka ne me donne pas envie d'en utiliser une, sauf que je ne sais pas comment le savoir (d'où ma question initiale).
votre avatar
La dette technique est déjà monstrueuse et va empirer de manière exponentielle ...
votre avatar
Visiblement, Debt as a service est déjà utilisé pour autre chose, c'est moche…
votre avatar
Ça me rappelle l'arrivée du low-code / no-code en entreprise, dont le vecteur d'attaque était par le métier pour lui montrer qu'il peut tout faire lui-même sans avoir à attendre ces connards de l'IT qui disent toujours non.

Résultat, projets montés à droite et à gauche chez des hébergements douteux à l'étranger, des droits d'accès pas gérés en mode openbar parce que c'est plus facile, des workflows qui traitent une quantité délirante de donnée parce que la minimisation c'est pour les losers, et j'en passe.

Remarque, de mon expérience, GCP aussi attaquait par le métier pour s'implanter en entreprise à coup de "t'as vu c'est facile t'as juste à cliquer là" (et faire pop une VM ouverte aux quatre vents connectée à ton réseau de prod, tout va bien).

On est dans la continuité de la CaaS * et du darwinisme de notre tissu économique.



  • Catastrophe as a Service

votre avatar
KILUKRU !

Et on nous reproche ensuite d'être des chieurs sur la sécurité/validation/MeP/etc.

Bin non, c'est un boulot avec un certain nombre de compétences pour ne pas lâcher de la M... en prod
Je sens que cet article va me servir d'argument sur mon utilité (et mon augmentation au passage) lors de la prochaine review avec les N+x.

L'IA c'est bien, l'IA utilisé intelligemment par des personnes qui savent ce qu'elles en font c'est mieux.
On ne donne pas les clés du 32t qui transporte une cargaison dangereuse au premier venu qui n'a pas le permis.
L'IA c'est pareil.
votre avatar
Clairement d'accord avec toi.
Franchement quand tu sais ce que tu fais, un agent "IA" pour aider c'est vraiment chouette. mais il faut déjà savoir ce que tu fais et comment, la stack, l'archi, les tests etc.
votre avatar
Mon manager m'a dit la dernière fois que les erreurs faites par les IAs peuvent être aussi faites par les humains et donc c'est normal qu'on va être à terme remplacés.

Quand tu as des gens tellement hors sols qu'ils te sortent des trucs pareils, pas sûr que ce soir un argument pour notre utilité pour eux (dans mon cas en tout cas, je croise les doigts pour que tes N+x soient moins cons)
votre avatar
À mon avis c'est plutôt l'inverse qui se prépare. En 2026, les devs qui savent vraiment utiliser l'IA sont demandés comme jamais. Y'a même des plateformes (comme olvan.co) qui se montent juste pour les recruter, parce qu'on sait tous comment ça se passe quand c'est un non-connaisseur qui s'en sert..
votre avatar
Ma boîte à «ça alors !» vient encore une fois d'exploser.
votre avatar
J'ai lu vos commentaires, si on voit une augmentation de l'usage de "l'auto" développement via IA c'est peut être aussi par ce que hélas une partie non négligeable de "professionnels" qu'on paye font de la M...
Alors pourquoi ne pas la produire soit meme gratuitement??
Franchement encore cette semaine j'ai analysé un site web généré par un "partenaire"
Entre les cookies non sécurisés et à la fin du remplissage d'un formulaire de prise de rdv qu'il affiche directement dans l'URL toutes les infos sensibles saisis dans le formulaire précédement. je suppose qu'il n'ont jamais entendu parlé d'OWASP...
le pire c'est que l'IT qui a commandé cela me dit " c'est vrai que je ne l'avais pas spécifié non plus"...
bref vu le nombre de société qui vendent des service "moins bons" que l'IA, si ca pouvait permettre une amélioration de la qualité produite par les humains ca serait déjà un bon début.
A noté que je suis conscient que le pb n'est pas forcément lié au développeur qui est mauvais, mais sur le fait qu'on ne lui a pas laisser le temps de faire les choses proprement, mais quand meme
votre avatar
TL ; DR : L'IA comme outil d'acceptation par le client, çaylebien. L'IA pour que le client génère lui même l'appli, çaylemal.

Comme indiqué dans un commentaire précédent, l'IA est assez mauvaise pour prendre les bonnes décisions techniques, mais franchement très bonne pour détecter les mauvaises décisions techniques. Un cahier des charges qui indique que les tests d'acceptation du client vont passer par une analyse du code fourni via une IA serait mille fois plus efficace pour inciter les prestataires à fournir du code valable.

Le client final est généralement peu compétent pour juger de la qualité du code (c'est par définition pas son métier), mais il peut être compétent à juger l'analyse faite par l'IA de la trempe de Mythos sur un prompt du genre "vérifie que le code dans le répertoire A répond bien à la spec du répertoire B et n'expose pas les données confidentielles". Si l'IA dit "là les données sont exposées en clair dans l'URL" en pointant le bout de code, ben le client il peut opposer ça au prestataire ; ça pourrait même être fun d'observer la conversation entre le développeur et l'IA pour justifier les décisions techniques...

C'est évidemment une opinion personnelle, mais je suis persuadé que cette manière de faire serait beaucoup plus intéressante que de balancer les specs à un vibe coding.
votre avatar
En phase on a fait tourner une IA pour analyser un vieux code oublié mais toujours utilisé (no comment) et il a vu des choses....
votre avatar
mais sur le fait qu'on ne lui a pas laisser le temps de faire les choses proprement, mais quand meme
On n'a jamais le temps de faire les choses proprement, mais on trouve toujours le temps de les refaire, les réparer, et les refaire encore.
votre avatar
On n'est pas encore au point où l'IA remplace les devs mais on a pas tous les moyens de payer une agence non plus...

L'entre-deux qui semble se dessiner : payer un expert pour auditer, ou pour vicoder à notre place. Parce que lui il sait quoi demander à l'IA, et surtout quoi vérifier après... C'est exactement le bout qui manque.

Vu passer olvan.co qui semble partir de cette idée. Si ça tient, ça pourrait éviter pas mal de ces catastrophes.