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.
Base de données de bornes de recharge électrique exposée suite à une mauvaise configuration des contrôles d’accès.
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.
Artefact de documentation généré automatiquement par IA et exposé publiquement sur un serveur 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.
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.
Un problème systémique
Réponse reçue après signalement de sécurité (responsible disclosure).
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.