Sécurité du vibe coding : que vérifier avant qu’une appli faite avec l’IA rencontre de vrais utilisateurs

Pourquoi une démo qui marche n’est pas encore une appli sûre

La sécurité du vibe coding commence par une observation simple. Vous décrivez une appli à Cursor, Lovable, Bolt ou v0, l’outil écrit le code, et tout fonctionne à l’écran. Dans cette boucle, personne ne demande si un inconnu pourrait ouvrir la même adresse et lire les données d’autrui. La démo passe parce que la seule personne qui la teste est aussi propriétaire de chaque ligne.

Le risque grandit le jour où arrivent de vrais utilisateurs. Avec eux viennent des noms, des commandes, des paiements. La liste OWASP Top 10:2021 des risques des applications web montre qu’il s’agit d’ingénierie ordinaire, non de piratage exotique. Les sections suivantes passent en revue les points faibles que rencontre d’abord une appli faite avec l’IA et ce qu’il faut vérifier avant le lancement.

Le contrôle d’accès défaillant, faiblesse numéro un de l’OWASP

Dans l’OWASP Top 10:2021, le contrôle d’accès défaillant occupe la première place, après être monté du cinquième rang. L’OWASP résume l’idée en une ligne : le contrôle d’accès applique une politique telle que les utilisateurs ne peuvent pas agir en dehors de leurs permissions prévues. L’OWASP note aussi que 94 % des applications de ses données ont été testées pour une forme de ce défaut : c’est donc le cas courant.

Dans une appli créée par prompts, la faille peut surgir à des endroits reconnaissables. Une page disparaît du menu mais s’ouvre si l’on tape son adresse, ce que l’OWASP appelle la navigation forcée. Une requête porte le numéro d’un compte ou d’une commande, et en le changeant on voit la fiche d’un autre client. Un point d’entrée d’enregistrement ou de suppression vérifie que la personne est connectée, pas que la fiche lui appartient. L’OWASP cite l’absence de contrôles sur POST, PUT et DELETE parmi ses exemples.

Les remèdes de l’OWASP sont simples. Refuser par défaut, sauf pour les ressources publiques. Appliquer les règles dans un code serveur de confiance, car le navigateur ne peut pas se surveiller lui-même. Fonder l’accès sur le propriétaire de chaque fiche et journaliser les échecs pour que quelqu’un remarque les tentatives répétées. Un bouton caché n’est pas une règle : si la seule protection est que le lien d’administration ne s’affiche pas, l’appli n’a aucun contrôle d’accès.

Clés et secrets qui finissent à la vue de tous

Toute appli qui parle à un service de paiement, de messagerie ou à un modèle d’IA a besoin d’une clé secrète. La documentation de Vercel décrit les variables d’environnement comme des paires clé-valeur configurées en dehors de votre code source. L’inverse est le défaut : une clé collée dans un fichier, versée dans le dépôt ou envoyée au navigateur avec la page.

La documentation de GitHub sur l’analyse des secrets indique qu’elle parcourt tout l’historique Git d’un dépôt, sur toutes les branches, à la recherche d’identifiants en dur comme les clés d’API, les mots de passe et les jetons. Il en découle un point que beaucoup oublient : supprimer la clé du fichier d’aujourd’hui ne l’efface pas de l’historique. Le guide de GitHub sur les secrets divulgués affirme que retirer le secret du code, pousser un nouveau commit ou recréer le dépôt n’empêche pas l’abus, et que tout secret divulgué doit être considéré comme compromis.

La solution consiste à révoquer la clé chez son fournisseur et à en émettre une nouvelle ; GitHub y voit l’étape de remédiation la plus importante. Consultez ensuite les journaux du fournisseur pour repérer des usages inconnus, et rangez la nouvelle clé dans les réglages de l’hébergeur. Vercel ajoute un détail pratique : une variable modifiée ne s’applique qu’aux nouveaux déploiements, il faut donc redéployer après la rotation.

Règles de base de données ouvertes et piège du Row Level Security

Quand le navigateur se connecte directement à une base hébergée, les règles de la base deviennent l’unique gardien. La documentation de Supabase sur le Row Level Security énonce le risque sans détour : une table d’un schéma exposé sans RLS est lisible et modifiable par tout rôle qui dispose de droits dessus. Activer le RLS ne suffit pas non plus. La même page précise que les tables ont aussi besoin de droits et de politiques adaptés, et qu’une fois le RLS activé l’API ne renvoie aucune donnée avec une clé publique tant qu’aucune politique n’existe.

Le second point de cette page concerne la clé puissante. Une clé secrète passe par le rôle de service, qui contourne le Row Level Security, et le guide déconseille de l’utiliser dans les navigateurs. Testez ensuite comme un étranger : connectez-vous avec un utilisateur et essayez de lire les lignes d’un autre. Le guide recommande lui-même de tester chaque table avec des cas d’autorisation et de refus pour chaque rôle.

Erreurs de configuration : valeurs par défaut, pages d’erreur et restes

L’OWASP nomme la famille suivante mauvaise configuration de sécurité et donne trois exemples du quotidien. Les comptes par défaut et leurs mots de passe sont toujours actifs et inchangés. La gestion des erreurs montre aux utilisateurs des traces d’appels ou d’autres messages trop bavards. Des fonctions inutiles sont activées, comme des pages, des comptes ou des privilèges superflus. Un projet généré peut cumuler les trois : un administrateur de démonstration, une route de débogage héritée de la première session, une erreur brute affichée à l’écran.

Le conseil de prévention de l’OWASP se lit comme une liste de rangement. Partir d’une plateforme minimale, sans fonctions, composants, documentation ni exemples inutiles. Puis vérifier les réglages par des contrôles automatisés plutôt que de mémoire.

Un contrôle de sécurité du vibe coding en une journée, avant le premier client

Commencez par cinq tests qui n’exigent aucun outil. Déconnectez-vous et ouvrez les adresses des pages privées. Connectez-vous en simple utilisateur et essayez les adresses d’administration. Changez le numéro dans l’adresse d’une fiche et voyez si celle d’un autre apparaît. Créez deux utilisateurs de test et tentez de lire, modifier et supprimer les données de l’autre. Enfin, provoquez une erreur exprès et lisez ce que la page affiche.

Regardez ensuite où se trouve chaque chose. Cherchez dans le dépôt et dans les fichiers chargés par le navigateur tout ce qui ressemble à une clé. Confirmez que les clés de production sont dans les réglages de l’hébergeur et non dans le code. Vérifiez que la production tourne sur sa propre base, séparée des données de test, et que quelqu’un d’autre que son constructeur peut se connecter en administrateur.

C’est un test rapide, pas un audit. L’OWASP et la documentation des plateformes citées font référence, et réussir signifie seulement que vous n’avez pas trouvé les failles évidentes, non qu’il n’y en a pas. Si l’appli traite des paiements, des données de santé, des données d’enfants ou des données personnelles de résidents d’autres pays, d’autres règles s’appliquent en plus. Faites examiner votre cas par un avocat.

Réparer ou reconstruire : décider avec une liste écrite

Réparer se justifie quand la structure est lisible, que les pages correspondent à de vraies fonctions et que les problèmes trouvés tiennent à des réglages et à quelques points d’entrée. Corriger les contrôles de propriétaire, déplacer les clés, ajouter des politiques de base et ranger le déploiement est un travail borné, avec une fin claire.

Reconstruire devient la réponse honnête quand chaque correction casse autre chose, quand personne ne sait dire où les données sont stockées, ou quand le modèle de données ne correspond pas au métier. Les rustines ne font alors qu’ajouter du poids. Ne décidez pas au feeling. Demandez à quelqu’un qui n’a pas écrit l’appli une liste écrite des problèmes classés par risque, et décidez devant cette liste. Elle transforme une dispute en comparaison.

Que préparer avant de commander le sauvetage d’une appli

Celui qui contrôle a besoin de peu pour commencer. Préparez l’accès au dépôt, à l’hébergement et à la base, donné par les invitations de chaque plateforme plutôt que par l’envoi de mots de passe. Écrivez sur une page ce que l’appli doit faire, qui l’utilise et ce qui ferait le plus mal en cas de panne. Avec cette feuille, un contrôle de la sécurité du vibe coding prend des jours et non des semaines.

VITON13 Studio propose un forfait intitulé Sauvetage d’une appli créée avec l’IA. Il comprend une revue de sécurité du code et des réglages, la correction de ce qui casse, la mise en place du déploiement et un nettoyage du code pour que le prochain développeur puisse le lire. Avant tout paiement, le studio rédige un brouillon gratuit : la liste des principaux problèmes trouvés. Le prix est fixe, à partir de 113 $, et le travail prend de 5 à 10 jours ouvrés.