Introduction : quand le vibe coding rencontre la cybersécurité

Le vibe coding est en train de transformer radicalement la manière dont les applications sont développées. Grâce aux assistants IA et aux LLM, il est désormais possible de générer une application complète — frontend, backend et API — simplement en décrivant l’intention fonctionnelle. Cette approche permet de produire des prototypes en quelques heures au lieu de plusieurs semaines.

Le produit :

L’application testée a été 100% vibe codée avec Opus 4.6 de Claude. Le développeur a mis deux semaines à générer un produit fini, très ergonomique et esthétique. Le développeur avait même demandé à Claude d’effectuer un pentest qui avait déjà remonté un certain nombre de failles plus ou moins critiques.

Mais une question essentielle se pose pour les équipes cybersécurité : Que se passe-t-il lorsque ces applications générées par IA arrivent en production sans audit de sécurité ?

Pour répondre à cette question, nous avons réalisé un pentest d’une application web entièrement, dans un contexte grey-box, avec un accès utilisateur standard.

Les résultats sont instructifs et plusieurs vulnérabilités critiques ont été identifiées le premier jour, notamment :

• Local File Inclusion (LFI)
• IDOR (Insecure Direct Object Reference)
• dépendances vulnérables
• fonction d’upload non sécurisée
• SSRF potentiel

Ces vulnérabilités illustrent un point clé : le code généré par IA est souvent parfaitement fonctionnel, mais rarement sécurisé par défaut.

Dans cet article, nous analysons les principales vulnérabilités découvertes et les leçons à retenir pour les RSSI, CISO et équipes DevSecOps.

Méthodologie du pentest

Le test de sécurité a été réalisé dans un contexte « grey-box web application pentest » .

Cela signifie que :

• l’application était accessible via Internet
• des comptes utilisateurs de test étaient fournis
• le code source n’était pas initialement accessible

L’objectif était de reproduire le comportement d’un attaquant externe.

La méthodologie utilisée s’appuie sur :

• OWASP Top 10
• tests automatisés
• analyse manuelle
• fuzzing des paramètres HTTP
• analyse des endpoints API

Outils utilisés :

• Burp Suite
• Nuclei
• tests manuels avancés

Cette approche permet d’identifier à la fois :

• les vulnérabilités techniques
• les problèmes de logique métier.

Vulnérabilité critique : Local File Inclusion (LFI)

La vulnérabilité la plus critique découverte lors du pentest est une Local File Inclusion (LFI).

Cette vulnérabilité permet à un attaquant d’accéder à des fichiers sensibles présents sur le serveur.

Dans l’application analysée, un paramètre contrôlé par l’utilisateur était directement utilisé pour charger des fichiers sur le système.

Voici l’équivalent de code vulnérable :

Le paramètre « full_path » n’était pas correctement filtré, un attaquant pouvait donc utiliser une attaque « path traversal » . Par exemple :

../../../../etc/passwd

Cette requête permet d’accéder au fichier système /etc/passwd, comme visible ci-dessous :

Impact de la LFI

Une LFI peut permettre :

• l’accès aux fichiers de configuration
• l’exposition des variables d’environnement
• la récupération de credentials
• l’accès au code source
• la préparation d’attaques ultérieures

Dans certains cas (malheureusement pas ici car les fichiers nécessaires n’ont pas été identifiés), une LFI peut même mener à une Remote Code Execution (RCE).

Cette vulnérabilité appartient à la catégorie OWASP A02 – Security Misconfiguration.

Dépendances vulnérables : le problème invisible

Un autre problème identifié concerne les dépendances utilisées par l’application.

Le frontend utilisait la librairie Vite version 5.4.10. Cette version comporte plusieurs vulnérabilités connues :

• CVE-2025-31125
• CVE-2025-30208
• CVE-2024-23331

Ces vulnérabilités permettent potentiellement, comme pour la LFI décrite ci-dessus, l’accès non autorisé à des fichiers du système. Ce problème est très courant dans les projets générés par IA.

Pourquoi ?

Parce que les assistants de code :

• sélectionnent automatiquement les dépendances
• n’intègrent pas de veille sécurité
• ne vérifient pas les versions vulnérables

Résultat : l’application peut contenir des vulnérabilités connues dès sa mise en production.

IDOR : accès aux données d’autres utilisateurs

Une autre vulnérabilité importante identifiée lors du pentest est une IDOR (Insecure Direct Object Reference).

Dans l’application, les profils utilisateurs étaient accessibles via un identifiant dans l’URL.

Exemple :

/employee/{user_guid}

Les GUIDs étant des identifiants uniques, ils sont impossibles à deviner. Il faut donc trouver un moyen pour que l’application nous les donne directement. Après un tour dans les différents appels API, nous avons identifié « /api/leaderboard », qui nous retourne les GUIDs de l’ensemble des employés :

En modifiant ce GUID avec l’un des GUIDs obtenus, par exemple celui du tech lead, il était possible d’accéder aux données d’autres utilisateurs :

Données exposées

Les endpoints API retournaient notamment :

• email
• rôle utilisateur
• identifiants internes
• hash de mot de passe (inutilisés malheureusement, l’application utilisant des tokens OAuth)

Impact

Ce type de vulnérabilité peut permettre :

• la fuite de données personnelles
• la préparation d’attaques ciblées
• l’escalade de privilèges

Cette vulnérabilité correspond à OWASP A01 – Broken Access Control.

Autres vulnérabilités observées

Le pentest a également mis en évidence plusieurs vulnérabilités supplémentaires :

• blind SSRF potentiel
• divulgation de versions logicielles
• headers HTTP de sécurité manquants
• politique de mot de passe faible
• environnement staging exposé
• Pas d’antivirus sur la fonction de téléversement de fichiers

Individuellement ces vulnérabilités sont souvent classées comme faible ou moyenne criticité. Mais combinées, elles peuvent faciliter des attaques plus avancées.

Pourquoi le vibe coding génère ces vulnérabilités

Le pentest met en évidence plusieurs faiblesses structurelles du vibe coding.

1. Malgré une revue de code de l’IA, elle ne peut pas encore tout voir

Les applications générées par IA passent rarement par une revue de sécurité humaine.

2. Validation d’entrées utilisateur insuffisante

Les modèles IA privilégient la fonctionnalité plutôt que la sécurité.

3. Contrôles d’accès incomplets

Les règles d’autorisation sont souvent oubliées ou mal implémentées.

4. Dépendances non sécurisées

Les versions de librairies utilisées ne sont pas vérifiées.

Comment sécuriser une application vibe codée

Les organisations qui adoptent le vibe coding doivent adapter leurs pratiques de sécurité.

Voici quelques recommandations.

Intégrer la sécurité dans le pipeline

• SAST
• DAST

Scanner les dépendances

• OWASP Dependency Check
• Snyk
• Dependabot

Appliquer le principe du moindre privilège

Chaque endpoint doit vérifier :

• l’authentification
• l’autorisation

Réaliser des pentests réguliers

Le vibe coding accélère le développement.

Mais il accélère aussi la propagation des vulnérabilités.

Conclusion

Le vibe coding ouvre une nouvelle ère dans le développement logiciel.

Mais notre pentest montre que les applications générées par IA présentent encore souvent :

• des vulnérabilités critiques
• des dépendances vulnérables
• des contrôles d’accès insuffisants

Pour les RSSI et CISO, la conclusion est simple : une application générée par IA doit être auditée comme n’importe quelle application critique.

Sinon, l’IA risque d’accélérer non seulement l’innovation… mais aussi les attaques.

Vous développez des applications avec IA ou vibe coding ?

Nos équipes réalisent des pentests spécialisés sur les applications générées par IA afin d’identifier les vulnérabilités avant leur exploitation.

Contactez-nous pour un audit de sécurité ou un pentest applicatif avancé.