Risques de sécurité du vibe coding : 8 points à vérifier avant le lancement

Le « vibe coding » consiste à créer un logiciel en décrivant ce que l’on veut à une IA et en acceptant ce qu’elle produit. Il a mis la création d’applications à la portée de fondateurs, de designers et d’opérationnels qui ne savaient pas coder il y a un an ou deux. Il a aussi créé un nouveau type de faille de sécurité : un logiciel qui fonctionne, paraît abouti et n’a jamais été examiné par quelqu’un qui pense comme un attaquant.

Ce guide énumère les huit risques de sécurité que nous vérifierions en premier dans une application issue du vibe coding, pourquoi chacun survient et que faire. Aucun ne vous oblige à lire du code. Ils exigent de poser les bonnes questions avant l’arrivée des vrais utilisateurs.

Pourquoi les applications générées par l’IA présentent un profil de risque distinct

Les outils d’IA optimisent pour que « ça marche ». Si une requête échoue à cause d’une permission, le moyen le plus rapide de la faire fonctionner est souvent de supprimer la permission. Si une clé d’API est nécessaire, l’endroit le plus rapide pour la mettre est là où le code peut l’atteindre, c’est-à-dire parfois le navigateur. L’application réussit tous les tests du créateur, car ces tests sont exécutés en tant que propriétaire.

C’est pourquoi les faiblesses ci-dessous sont rarement de spectaculaires bugs de code. Ce sont des décisions manquantes : qui est autorisé à faire cela, où ce secret doit-il se trouver, que se passe-t-il si quelqu’un détourne cette fonctionnalité.

Risque 1 : contrôle d’accès défaillant

Le problème le plus courant et le plus grave. Un client peut lire, modifier ou supprimer les données d’un autre client, ou un utilisateur ordinaire peut accéder aux fonctions d’administration, parce que les contrôles n’existent que dans l’interface et non sur le serveur ou la base de données. Dans les projets Supabase, cela signifie généralement une Row Level Security absente ou insuffisante, que nous abordons dans sept erreurs de RLS commises par les applications créées avec l’IA.

Test : utilisez deux comptes et essayez d’accéder aux données de l’autre en modifiant les identifiants dans les URL et les requêtes.

Risque 2 : secrets exposés

Des clés d’API, des mots de passe de base de données et des jetons de service se retrouvent dans le code frontend, dans des dépôts publics ou dans des transcriptions de chat. Tout ce qui est envoyé au navigateur est public, et les clés commitées dans Git restent dans l’historique même après la suppression du fichier.

Correctif : conservez les secrets dans des variables d’environnement côté serveur, recherchez des clés dans votre bundle et votre dépôt, et renouvelez tout ce qui a déjà été exposé.

Risque 3 : entrées non validées

Les formulaires, les URL et les paramètres d’API sont contrôlés par l’attaquant. Si l’application construit des requêtes de base de données en concaténant des chaînes, ou affiche les saisies des utilisateurs dans les pages sans les encoder, elle peut être vulnérable à l’injection SQL ou au cross-site scripting. Les frameworks et générateurs de requêtes modernes préviennent l’essentiel de ces risques par défaut, mais le code généré les contourne parfois.

Correctif : utilisez des requêtes paramétrées, validez les entrées côté serveur et examinez tous les endroits où des requêtes brutes ou du HTML brut sont construits.

Risque 4 : dépendances hallucinées et obsolètes

Les outils d’IA suggèrent parfois des paquets logiciels qui n’existent pas. Des attaquants ont commencé à enregistrer ces noms, avec du code malveillant à l’intérieur, dans l’espoir qu’un développeur ou un outil automatisé les installe. On parle parfois de slopsquatting. Par ailleurs, les projets générés figent souvent d’anciennes versions présentant des vulnérabilités connues.

Correctif : vérifiez que chaque dépendance existe, est largement utilisée et correspond bien à celle que vous visiez, commitez votre lockfile et exécutez une analyse de vulnérabilités des dépendances à chaque build.

Risque 5 : paramètres par défaut non sécurisés

Par exemple : un réglage cross-origin permissif qui autorise n’importe quel site à appeler votre API, le mode debug laissé activé en production, des messages d’erreur détaillés qui révèlent des éléments internes, des buckets de stockage publics et des comptes administrateur par défaut. Chacun se corrige en une ligne et chacun est facile à manquer.

Correctif : examinez la configuration de production séparément de celle de développement et désactivez tout ce qui n’existe que par commodité.

Risque 6 : aucune limite d’utilisation ni de coût

Les applications dotées de fonctions d’IA appellent souvent un modèle payant pour le compte de chaque visiteur. Sans limites de débit, quotas par utilisateur et plafonds de dépenses, un script peut générer une facture énorme ou mettre le service hors service. Les formulaires de connexion et d’inscription sans limites ouvrent la porte aux tentatives de devinette de mots de passe et aux inscriptions par des bots.

Correctif : ajoutez une limitation de débit, définissez des plafonds d’utilisation sur chaque clé tierce et déclenchez une alerte en cas de flambée des dépenses.

Risque 7 : injection de prompt dans vos propres fonctions d’IA

Si votre application permet à un modèle de lire du contenu utilisateur, de parcourir des pages ou d’appeler des outils, des attaquants peuvent y dissimuler des instructions pour orienter le modèle. Le danger augmente avec ce que le modèle peut faire : lire des données privées, envoyer des messages ou modifier des enregistrements. Nous expliquons les types d’attaques et les tests dans notre guide sur le red teaming de LLM par rapport à un test d’intrusion d’application web.

Correctif : accordez aux outils du modèle le moindre privilège possible, exigez une approbation humaine pour les actions risquées et considérez tout ce que le modèle produit comme non fiable.

Risque 8 : pas de journalisation, donc aucun moyen de savoir

De nombreuses applications issues du vibe coding ne peuvent pas répondre à des questions élémentaires lorsqu’un problème survient : qui a accédé à quoi, quand l’erreur a-t-elle commencé, quelle requête a échoué. Sans journaux ni supervision, un incident peut durer des semaines avant que quiconque ne le remarque, et vous ne pouvez pas déterminer ce qui a été exposé.

Correctif : centralisez les journaux d’erreurs, conservez des journaux d’audit pour les actions sensibles et configurez des alertes qui parviennent à une vraie personne.

Un passage en revue de sécurité de 30 minutes à faire dès aujourd’hui

1. Créez deux comptes de test et essayez de voir, modifier et supprimer les données de l’autre.
2. Recherchez dans votre dépôt et dans le code de votre site compilé des clés d’API et des jetons de service.
3. Vérifiez quels buckets de stockage et quelles tables de base de données sont lisibles publiquement.
4. Ouvrez les requêtes réseau de votre application et cherchez des secrets, des URL internes ou des erreurs trop détaillées.
5. Listez chaque dépendance et vérifiez qu’elle est réelle, à jour et voulue.
6. Vérifiez que des limites de débit et des plafonds de dépenses existent sur la connexion, l’inscription et toute fonction d’IA.
7. Vérifiez que les erreurs et les actions sensibles sont consignées quelque part où vous pouvez les lire.

Ce que les outils d’IA peuvent et ne peuvent pas faire à ce sujet

Vous pouvez demander à l’IA de relire son propre code pour détecter ces problèmes, et elle en trouvera certains. Mais elle part des mêmes hypothèses que celles qui ont produit le problème, et elle ne peut pas tester votre système déployé avec deux vrais comptes. Considérez une revue de sécurité par IA comme une première passe, pas comme une validation.

Lorsque l’enjeu concerne de vrais utilisateurs, des données personnelles ou des paiements, faites appel à quelqu’un d’indépendant. Un audit technique d’applications IA couvre le contrôle d’accès, les secrets, les permissions de données, les paiements et le déploiement, et se termine par une liste de correctifs hiérarchisée. Si vous savez déjà ce qui est cassé, la réparation et mise en production d’applications IA le corrige et le met en ligne de manière maîtrisée. Notre liste de contrôle de production en 20 points relie ces vérifications.