Un rapport publié sur DEV Community décrit une « faille de sécurité à 0 $ » dans laquelle 24 664 applications créées par IA auraient exposé plus de 80 000 enregistrements d'utilisateurs, y compris des numéros de passeport, via des bases de données Supabase. Cette fuite de données d'applications créées par IA via Supabase rappelle utilement que la rapidité de développement et la sécurité des données des utilisateurs ne sont pas la même chose.

Une note sur les sources : le matériel source dont nous disposons se limite au titre du rapport et à un court résumé. Il ne nous indique pas qui a identifié l'exposition, comment les applications ont été trouvées, ni quelles applications précises ont été affectées. Cet article s'en tient à ce que le rapport énonce et identifie clairement tout contexte général comme tel.

Comment des bases de données mal configurées ont exposé des enregistrements d'utilisateurs

Selon le titre du rapport, les enregistrements exposés provenaient d'applications créées avec des outils d'IA qui utilisaient Supabase comme backend. Le titre présente également l'incident comme n'ayant rien coûté à réaliser, ce qui suggère qu'aucun piratage sophistiqué n'a été impliqué. La source ne détaille pas les mécanismes.

À titre de contexte général (non tiré du rapport) : Supabase est un service de base de données hébergé, et l'accès à ses données est généralement contrôlé par des règles définies par celui qui construit l'application, comme la sécurité au niveau des lignes (row level security). Si ces règles sont absentes ou trop permissives, les données peuvent être lisibles par des personnes qui ne devraient pas les voir. Il s'agit d'un problème de configuration plutôt que d'une faille nécessitant une effraction.

Pourquoi le vibe coding crée cette faille de sécurité

Le « vibe coding » consiste à construire un logiciel en décrivant ce que l'on veut à un outil d'IA et en acceptant le code généré avec peu de relecture manuelle. Cela peut transformer une idée en application fonctionnelle en quelques heures. Le compromis est que les paramètres de sécurité sont faciles à négliger lorsque l'application semble fonctionner.

Une application peut avoir l'air et se comporter parfaitement alors que son backend est ouvert à quiconque sait où chercher. Rien à l'écran n'indique à un utilisateur, ni souvent au développeur, que quelque chose ne va pas. C'est pourquoi une interface soignée est un mauvais indicateur du soin apporté à la protection des données.

Cela s'inscrit aussi dans un schéma plus large où les outils d'IA modifient le paysage des risques. Notre couverture de la façon dont le gang de rançongiciels Aurora déploie un agent de codage IA dans ses attaques et dont Qilin utilise des outils d'IA alors que les attaques par rançongiciels augmentent au Japon montre que l'IA accélère aussi le travail du côté des attaquants.

Quelles données ont été exposées et qui est à risque

Le rapport indique que les enregistrements exposés sont au nombre de plus de 80 000 et comprennent des numéros de passeport. Les détails de passeport figurent parmi les identifiants les plus sensibles qu'une personne puisse partager, car ils sont difficiles à remplacer et peuvent faciliter la fraude à l'identité lorsqu'ils sont combinés à un nom, une adresse e-mail ou une date de naissance.

La source ne précise pas quels autres champs ont été exposés ni dans quels pays se trouvent les utilisateurs affectés. Quiconque s'est inscrit à une application récente et a téléversé des documents d'identité ou des informations personnelles fait potentiellement partie du groupe à surveiller, en particulier si l'application provient d'un développeur petit ou inconnu.

Ce que cela signifie pour vous

Vous ne pouvez généralement pas voir comment une application protège sa base de données, aussi la défense pratique consiste-t-elle à contrôler ce que vous confiez.

  • Remettez en question la nécessité. Si une application demande un numéro de passeport ou une copie de pièce d'identité, demandez-vous si le service en a vraiment besoin.
  • Vérifiez le développeur. Recherchez une entreprise nommée, une politique de confidentialité et un moyen de contacter le support. Soyez prudent avec les applications toutes récentes qui n'ont rien de tout cela.
  • Utilisez des identifiants uniques. Un mot de passe distinct et un alias e-mail pour chaque nouveau service limitent les dégâts si un ensemble d'enregistrements est exposé.
  • Omettez les champs facultatifs. Ne renseignez pas les numéros de téléphone, les adresses et les téléversements de documents sauf s'ils sont obligatoires.
  • Surveillez les escroqueries consécutives. Les enregistrements exposés sont souvent réutilisés pour l'hameçonnage et la fraude, comme on l'a vu lorsque les enregistrements d'utilisateurs de Paidwork ont été ajoutés à HIBP.

Comment évaluer les applications et limiter ce que vous partagez

Avant de créer un compte avec une nouvelle application, prenez une minute pour l'examiner. Privilégiez les services qui expliquent comment ils stockent les données et qui ont un historique établi. Si une application exige des documents d'identité, demandez-vous s'il existe une alternative plus établie.

Si vous créez vous-même des applications, le conseil général est de vérifier les règles d'accès à la base de données avant le lancement plutôt que de faire confiance au code généré, et de tester votre application en tant que visiteur non authentifié pour voir quelles données sont accessibles.

À retenir

L'incident signalé de fuite de données d'applications créées par IA via Supabase montre qu'une application fonctionnelle n'est pas nécessairement sécurisée. Commencez par vérifier si votre adresse e-mail apparaît dans des fuites connues à l'aide d'un service tel que Have I Been Pwned, et changez les mots de passe de tout compte concerné. Ensuite, ne donnez à chaque nouvelle application que le minimum de données personnelles dont elle a besoin. Pour voir comment les enregistrements exposés sont exploités, lisez notre couverture de la fuite Paidwork qui a exposé 23 M d'e-mails et des données bancaires.