Le « vibe coding » transforme le cloud en surface d’attaque

Les outils d'IA et les plateformes cloud ont rendu la création d'applications quasi instantanée — mais la sécurité, elle, n'a pas suivi. En 48 heures d'analyse passive, plus de 9 000 infrastructures révèlent bases de données ouvertes, clés exposées et fichiers de diagnostic accessibles en production. Ce n'est pas un bug de l'IA : c'est une crise de gouvernance, amplifiée par la vitesse.

On n’a jamais aussi facilement créé des applications. Entre les outils de Backend-as-a-Service (BaaS) et les générateurs de code assistés par IA, il suffit aujourd’hui de quelques prompts pour passer d’une idée à une application en production. Des outils comme Supabase, Firebase ou encore des environnements de développement assistés par IA ont considérablement réduit le temps entre prototypage et déploiement en production. Cette pratique, souvent résumée sous le terme de "vibe coding", est présentée comme une révolution de productivité. Et c’est vrai ! Mais la prise en compte de la sécurité n'a pas été au rendez-vous.

Résultat : on ne parle plus seulement de vulnérabilités isolées, mais d’un phénomène systémique de mauvaises configurations à grande échelle. Un phénomène déjà documenté… mais qui s’étend. Des travaux récents, notamment relayés par Wired et l’analyse de Red Access (via Dor Zvi), ont montré que plus de 5 000 applications générées par IA exposaient déjà des données sensibles sur Internet, parfois en clair.

Ce que montre l’exposition côté BaaS

Les travaux récemment relayés mettent principalement en lumière les risques liés aux applications hébergées directement sur des plateformes de génération assistée par IA. En m’appuyant sur ces premières observations, j’ai souhaité élargir l’analyse à des applications et infrastructures ne reposant plus directement sur ces plateformes, mais déployées sur des architectures BaaS et cloud plus classiques, parfois derrière des domaines personnalisés ou intégrées dans des environnements de production plus complexes.

Sur une fenêtre d’observation de 48 heures, j’ai effectué une analyse passive d’environ 9 000 actifs reposant sur des architectures BaaS et cloud modernes. Cette analyse révèle des bases de données accessibles sans authentification correcte, des clés de service exposées côté client, ainsi que des configurations de sécurité incomplètes ou jamais activées. Dans certains cas, des artefacts d’audit générés automatiquement, parfois issus d’outils ou de workflows assistés par IA, sont laissés accessibles publiquement.

Le constat est important : les problèmes observés ne se limitent pas aux plateformes de génération elles-mêmes. Une fois les applications déplacées, adaptées ou intégrées dans d’autres environnements cloud, les mêmes erreurs réapparaissent sous d’autres formes — gestion inadéquate des secrets, exposition d’API, règles d’authentification incomplètes ou contrôles de sécurité absents.

On observe également que des fichiers de diagnostic produits par ces outils se retrouvent directement exposés sur des environnements de production.

Ce ne sont pas des vulnérabilités isolées, mais la répétition de schémas connus. Ce ne sont pas des failles “IA”, mais des failles de gouvernance et de configuration.

Le « vibe coding » transforme le cloud en surface d’attaque — Artefact de documentation généré automatiquement par IA et exposé publiquement sur un serveur de production

Des étapes fréquemment contournées

En fait, le problème, ce n'est pas l’IA. Les outils de génération de code ou les plateformes BaaS ne “créent” pas des vulnérabilités. Ils rendent simplement extrêmement facile le déploiement d'applications sans passer par les étapes classiques de validation de sécurité : revue d’architecture, contrôle des accès, validation SecOps, configuration explicite des secrets, tests de sécurité avant production. Dans le modèle actuel, ces étapes sont souvent contournées ou jamais formalisées. Le résultat, c’est une explosion de systèmes fonctionnels… mais mal sécurisés.

Ce phénomène n’est certes pas nouveau puisqu'on l'a déjà vu avec les buckets S3 mal configurés, les API publiques non protégées ou les dashboards exposés sans authentification. La différence aujourd’hui, c’est l’échelle. Le couple IA + BaaS réduit drastiquement le coût de création d’une application. Mais le coût de sécurisation, lui, reste stable, voire augmente avec la complexité des stacks. C’est ce décalage qui crée une accumulation massive d’expositions.

Ce qui rend la situation particulièrement difficile à absorber aujourd’hui, c’est la combinaison de trois dynamiques :

1. Accélération de la création. Créer et déployer une application est devenu en effet quasi instantané.

2. Accélération de la découverte. Les outils OSINT et les techniques d’analyse automatisée permettent de repérer ces expositions très rapidement.

3. Accélération de la surface d’attaque. Le nombre de systèmes exposés augmente plus vite que la capacité humaine à les auditer.

Résultat : une dette de sécurité structurelle s’accumule.

Ce qui rend la situation particulièrement difficile à absorber aujourd’hui, c’est la combinaison de trois dynamiques : — Réponse reçue après signalement de sécurité (responsible disclosure).

Un problème systémique

Un point rarement abordé dans ces discussions est la manière dont ces vulnérabilités sont (ou ne sont pas) corrigées. Dans de nombreux cas, les chercheurs en sécurité tentent de signaler ces expositions via des démarches de divulgation responsable (responsible disclosure). Mais en pratique, on déplore l'absence de contact sécurité identifié, de fichier security.txt, de processus clair de traitement des alertes, ainsi qu'une confusion entre signalement légitime et activité malveillante. Cette friction organisationnelle prolonge la durée d’exposition des données. Et à grande échelle, cela devient un problème systémique.

Il serait simpliste de blâmer uniquement les outils IA ou les plateformes BaaS. Le problème est distribué parmi :

- Les développeurs “no-code / low-code” qui ne maîtrisent pas toujours les enjeux sécurité,

- Les entreprises qui accélèrent le time-to-market sans gouvernance suffisante,

- Les plateformes qui privilégient la friction minimale au détriment du “secure-by-default” et parfois l’absence de culture sécurité dès la conception.

Vers un modèle “secure-by-default” réel

Les solutions existent, mais elles impliquent un changement de posture :

- rendre la sécurité obligatoire avant mise en production,

- activer les protections par défaut côté BaaS, mieux encadrer la gestion des secrets, intégrer des contrôles automatisés avant déploiement,

- structurer la réception des signalements (canaux dédiés, security.txt, etc.). Ce n’est pas une question d’outils supplémentaires, c’est une question de discipline de déploiement.

L’IA et les plateformes BaaS ont changé une chose fondamentale : le problème n’est plus de créer des systèmes. Le problème est de les gouverner. Et tant que la capacité de déploiement restera largement supérieure à la maturité sécurité des environnements, on continuera à voir apparaître ce type d’exposition systémique.

Pas parce que les technologies sont mauvaises.

Mais parce que la vitesse a dépassé la gouvernance.