Le vibe coding et la faille de sécurité de Tea : la sécurité ne devrait jamais passer au second plan
Pourquoi les principes de gouvernance, de visibilité et de sécurité sont essentiels dans le développement des applications modernes
Ce qu’il faut retenir :
- La sécurité doit être une priorité d’emblée : les MVP réalisés à la hâte et le développement externalisé négligent souvent les mesures de sécurité fondamentales, ce qui entraîne des vulnérabilités.
- Les erreurs de configuration des API sont un vecteur d’attaque courant : les deux violations de l’application Tea ont été causées par des politiques d’authentification et d’autorisation insuffisantes.
- Le « vibe coding » (litt. « programmation au ressenti ») est risqué pour les applications de production ; un développement rapide et non structuré peut fonctionner pour les prototypes, mais pas pour les applications qui gèrent des données sensibles.
Les récentes violations de sécurité que l’application de rencontres Tea a subies sont des exemples classiques de mauvaises pratiques de développement, de sécurité et d’exploitation (DevSecOps). Cette application est une plateforme de prévention dans le domaine des rencontres réservée aux femmes, permettant aux abonnées de partager leurs expériences dans une communauté privée. L’application propose plusieurs outils, notamment un chat de groupe et la possibilité de noter et d’évaluer les hommes via un processus similaire à un avis Yelp. En dehors des questions de confidentialité, l’application utilise l’intelligence artificielle (IA) et des photos d’identité officielles (ou vérifiées par d’autres moyens) comme un permis de conduire, pour s’assurer que l’abonnée est bien une femme.
Ce processus de vérification, ainsi que le chat de groupe et la messagerie personnelle, sont les raisons qui nous amènent. Selon le fondateur, l’application Tea originale a été créée par une équipe de deux développeurs recrutés par Toptal, et je présume que les fuites sont dues au fait que l’on ne s’est pas préoccupé de la sécurité pendant la phase de développement du produit minimum viable (MVP).
Les deux violations – la fuite initiale de la base de données Firebase (DB) et la fuite ultérieure des conversations – se sont produites en raison du problème standard qui affecte les interfaces de programmation d’applications (API), tel que décrit par l’Open Worldwide Application Security Project (OWASP). Plus précisément, ces deux problèmes ont été causés par des politiques d’authentification et d’autorisation défaillantes. La première est une fuite de données Firebase classique, qui se produit lorsque les politiques de sécurité ne sont pas configurées manuellement, un problème connu depuis longtemps. La seconde est plus grave : n’importe quel utilisateur peut utiliser sa clé API pour télécharger les conversations d’autres utilisateurs. L’équipe de développement n’a pas identifié ni corrigé ces problèmes alors que l’application était une cible de choix pour les pirates. Elle aurait tout intérêt à se pencher sur ce document de l’OWASP pour améliorer ses processus de sécurité.
Le vibe coding fait fureur, pas seulement dans les communautés de programmation, mais aussi dans les cercles de gestion de produits. De nombreuses entreprises tentent désormais de s’entourer de chefs de produit polyvalents (PM) qui gèrent tout, des conditions requises à la création d’applications et qui, vraisemblablement, restent éveillés toute la nuit pour assurer le support de production. Selon le consensus général, et j’y adhère totalement, c’est une mauvaise idée. S’il est possible pour un PM technique de produire une preuve de concept (PoC) ou un prototype, je ne crois pas du tout à la pratique du « vibe coding » pour une production de qualité.
Les failles de l’application Tea montrent pourquoi c’est une mauvaise idée. Même si nous ne savons pas si l’application a été programmée par vibe coding, le développement initial a été sous-traité à des freelances par un décideur non technique. Les hallucinations n’affectent pas seulement les réponses, mais aussi la sécurité. L’IA que vous utilisez comprend-elle les concepts élémentaires de sécurité ? Si vous souhaitez à tout prix lancer une application fonctionnelle, le code sera-t-il compréhensible ? Et face à une dette technique, comment allez-vous identifier et résoudre les problèmes ? Le dépannage et la correction d’un code hérité écrit par un humain sont particulièrement pénibles, même lorsque le programmeur ajoute des commentaires du genre « Ne pas supprimer cette variable env ! ».
François Chollet commente le code hérité d’une IA générative
François Chollet, créateur de la bibliothèque d’apprentissage profond Keras, replace cette question dans son contexte dans le tweet ci-dessus. Le problème, c’est que les ingénieurs logiciels vont devoir corriger le désastre généré par l’IA, à savoir du ’code spaghetti au pesto, cheeseburger, fusilli et ananas.’ Aujourd’hui, les gens sont coincés par du code ajouté à la hâte et écrit il y a des lustres, qu’ils doivent gérer avec une base de données Access dont le mot de passe est oublié depuis longtemps. Sans parler des articles qui expliquent régulièrement combien les programmeurs COBOL (Common Business-Oriented Language) expérimentés et capables de comprendre la logique métier sont précieux parce que personne d’autre n’est capable de comprendre et de réparer les systèmes existants.
Ou, comme le dit un mème :
Programmation d’un meme basé sur « The Office », via Reddit
En règle générale, l’automatisation est une bonne chose. Si cela permet de faire son travail plus rapidement et de se consacrer à des tâches plus productives, c’est parfait. Toutefois, le problème se pose lorsque les outils d’automatisation ne disposent pas des garde-fous de sécurité adéquats. Étant donné la prolifération actuelle des outils de sécurité qui communiquent rarement entre eux, les choses se compliquent. Il faut mettre en place une gouvernance, puis assurer la visibilité, et enfin appliquer des mesures de protection, et tout cela aurait dû être fait depuis des années. La sécurité est déjà un problème difficile à résoudre, et la montée en puissance de l’automatisation alimentée par l’IA générative ne fera qu’aggraver la situation. Les applications low-code/no-code sont comme des stagiaires à qui l’on confierait les clés des déploiements de production.
Nous avons déjà vécu cela auparavant et continuons à répéter les mêmes erreurs. La CVE-2025-53773 (Common Vulnerabilities and Exposures) est une vulnérabilité par injection de prompt dans Copilot qui permet à un pirate d’exécuter du code localement. Elle est similaire aux risques d’injection de commandes décrits par l’OWASP, qui existent depuis le début de la sécurité Web. Autre exemple, moins axé sur la programmation : des agents d’IA qui fonctionnent avec Notion. En l’absence de protections assurées par un contrôle d’accès basé sur les rôles (RBAC), ces agents peuvent accéder à des informations dans l’ensemble des systèmes de données. Des prompts légitimes peuvent transmettre de mauvaises informations à des pirates. Des études ont mis en évidence les risques d’exfiltration par injection de prompt, et Notion a depuis annoncé des mesures de protection supplémentaires.
La gouvernance et la sécurité sont plus importantes que jamais. Mettre en place la bonne gouvernance et les garde-fous appropriés est essentiel, tout comme une défense en profondeur pour vos applications existantes.
Capture d’écran du blocage d’une tentative d’accès à OpenAI
Rapport 2025 sur les violations de la sécurité des e-mails
Principales conclusions concernant l’expérience et l’impact des failles de sécurité des e-mails sur les organisations du monde entier
S’abonner au blog de Barracuda.
Inscrivez-vous pour recevoir des informations sur les menaces, des commentaires sur le secteur et bien plus encore.
Rapport d’informations de 2025 sur les clients des fournisseurs de services managés
Panorama mondial sur les besoins et attentes des organisations vis-à-vis de leurs fournissuers de services managés en cybersécurité