Vibe coding : une application qui fonctionne n’a pas encore prouvé sa sécurité

Un formulaire accepte une inscription. Un document s’enregistre. Une réponse d’IA apparaît. Le prototype donne l’impression d’un service achevé parce que ses fonctions visibles répondent à la demande. Reste une autre série de questions : un utilisateur accède-t-il aux documents de son voisin ? Une ancienne session fonctionne-t-elle encore après suspension du compte ? Plusieurs requêtes simultanées contournent-elles le quota prévu ? La démonstration habituelle laisse ces situations hors champ.

Le développement assisté par IA ne supprime aucune de ces exigences. Il change surtout la relation du créateur au logiciel : des composants, des permissions et des services externes s’assemblent parfois avant que leur propriétaire en maîtrise les interactions. Le problème apparaît au moment de l’ouverture au public, lorsque l’application accueille des usages inattendus et que les erreurs touchent des personnes, des données ou une facture.

La réussite du parcours masque ses conditions de sécurité

Tester une fonction consiste généralement à vérifier le résultat recherché. Auditer sa sécurité demande aussi de vérifier les résultats interdits. Pour une page de documents, cela revient à examiner les appels qui alimentent l’écran, les droits appliqués par le serveur, les règles du stockage et les chemins d’export. Un bouton masqué à un membre ordinaire ne suffit pas si la fonction administrative reste accessible par une requête directe.

OWASP distingue précisément les défauts d’autorisation portant sur les objets, sur leurs propriétés et sur les fonctions d’une API. Un compte connecté n’a pas nécessairement le droit de lire chaque document, de modifier chaque champ ou d’utiliser chaque opération. Le contrôle doit suivre la ressource et l’action demandées. La complexité d’un identifiant apporte peu de protection lorsque le serveur omet cette décision.

Prenons un scénario fictif. Deux entreprises utilisent un outil de rédaction. Chacune retrouve ses dossiers dans son espace. Une erreur de cache suffit pourtant à servir le résultat de la première à la seconde. Les écrans, examinés séparément, paraissaient corrects. La vérification doit donc porter sur les échanges entre comptes, sur les changements de droits et sur les traitements différés.

Changer le rôle de l’IA ne crée pas un auditeur indépendant

Une consigne circule facilement : demander à l’assistant de quitter son rôle de développeur pour devenir un auditeur hostile. L’exercice a un intérêt : il oriente la recherche vers les abus et les contournements. Sa formulation ne donne cependant ni accès aux réglages de l’hébergeur, ni connaissance automatique de toutes les routes, ni indépendance vis-à-vis des hypothèses déjà inscrites dans le projet.

La qualité du résultat se juge aux éléments vérifiables. Quels fichiers ont été lus ? Quelle version a été examinée ? Quels tests ont réellement été exécutés ? Une référence précise dans le code existe-t-elle ? Une réponse très assurée, accompagnée d’une liste de bonnes pratiques, reste insuffisante pour conclure. L’assistant doit aussi déclarer ses limites : historique Git absent, configuration cloud inaccessible, test proposé, mais non lancé, déploiement différent du code fourni.

Un référentiel sert à formuler des exigences vérifiables

L’OWASP Application Security Verification Standard fournit une base d’exigences techniques. Sa version 5.0.0, publiée en mai 2025, couvre notamment authentification, sessions, autorisations, fichiers, configuration et journalisation. Le Web Security Testing Guide complète cette approche par des méthodes de vérification. Les deux ressources remplissent des fonctions complémentaires : définir le comportement attendu, puis organiser les essais qui l’éprouvent.

Leur nom ne constitue toutefois aucun label pour une checklist maison. Le dossier proposé par IN DATA VERITAS rassemble 72 contrôles pratiques, reliés aux références pertinentes. Cette sélection ne reprend pas l’ensemble des exigences ASVS et ne vaut ni certification ni conclusion de conformité à un niveau du standard. Son objectif : donner au créateur, au développeur et au relecteur un langage commun pour décrire les risques et les preuves attendues.

Le risque atteint aussi le budget

Une application reliée à des services facturés à l’usage engage des ressources à chaque traitement. L’API Security Top 10 d’OWASP inclut la consommation non maîtrisée : calcul, mémoire, stockage, mais aussi e-mails, SMS et autres prestations payantes. Pour une application utilisant un modèle, le sujet concerne également les appels successifs, les outils, les recherches et les reprises après erreur.

Limiter la longueur d’une réponse ne borne pas le nombre de demandes. Un quota par utilisateur ne fixe pas à lui seul la dépense globale. Le guide distingue donc débit, volume, concurrence et budget. Il propose de vérifier les conditions d’accès avant l’appel payant, de réserver une enveloppe bornée et de rapprocher ensuite cette réservation de la consommation connue. Une requête dont la réponse s’est perdue a parfois déjà été facturée.

Les essais doivent notamment confronter les mécanismes à la simultanéité. Avec un seul crédit restant, plusieurs demandes envoyées ensemble ne doivent pas toutes être acceptées. La vérification porte aussi sur les réglages du fournisseur : une alerte et un plafond bloquant remplissent des fonctions différentes. Leur portée et leur délai d’application restent à établir pour le compte réellement utilisé. Aucun montant générique ne remplace cette vérification.

L’IA dans le produit ajoute ses propres frontières

Une application codée avec l’aide d’une IA n’intègre pas nécessairement un modèle dans son fonctionnement. Lorsqu’elle en utilise un, des contrôles supplémentaires deviennent nécessaires. Le référentiel OWASP consacré aux applications LLM décrit notamment les injections de prompt, les faiblesses des systèmes documentaires et les droits excessifs accordés aux outils. [6]

Un document importé, une page récupérée ou le résultat d’un connecteur contient des données extérieures au système. Certaines instructions présentes dans ce contenu cherchent à détourner le comportement du modèle. La protection des comptes doit donc rester assurée par l’application : filtrage des documents accessibles, validation des arguments d’un outil, restriction des destinations et contrôle des actions sensibles. Une consigne demandant au modèle de respecter les droits ne constitue pas cette barrière technique. [7]

La preuve manque : il faut l’écrire

La grille proposée utilise quatre statuts. PASS signifie que l’exigence est satisfaite dans le périmètre examiné, avec une preuve adaptée. FAIL indique un écart établi. UNKNOWN signale que les éléments disponibles ne suffisent pas. N/A désigne un contrôle non applicable, avec justification. Chaque statut reste lié à une version, à un environnement et à une date.

Cette distinction évite deux erreurs symétriques : déclarer une protection acquise parce qu’une bibliothèque est installée, ou annoncer une vulnérabilité parce qu’un mot sensible apparaît dans un fichier. Une clé visible dans le navigateur, par exemple, exige d’identifier sa fonction. Supabase distingue les clés publiables des clés secrètes privilégiées. La question décisive porte sur les droits réellement ouverts, pas sur la seule présence du terme « clé API ».

La gravité demande elle aussi une justification : données accessibles, privilèges nécessaires, utilisateurs touchés, impact et conditions d’exploitation. Un pourcentage global de contrôles réussis efface ces différences. Une seule fuite entre clients peut compter davantage que plusieurs dizaines de vérifications secondaires validées. Un UNKNOWN sur ce point réclame une investigation avant l’ouverture, même sans exploitation démontrée.

Trois documents pour organiser le travail

Le premier PDF expose la méthode, les 72 contrôles, les scénarios de test et les références. Le deuxième fournit une grille remplissable pour consigner statuts, preuves, fichiers et lignes, risques, corrections et résultats. Le troisième contient des consignes prêtes à transmettre à un assistant IA, depuis l’inventaire jusqu’à la contre-vérification. Les trois partagent les mêmes identifiants pour suivre un problème sans le perdre entre deux rapports.

Les essais actifs s’effectuent sur un périmètre autorisé, avec des données fictives, un volume borné et des conditions d’arrêt. Une revue du code ne démontre ni la restauration d’une sauvegarde ni l’efficacité d’un plafond cloud. Selon les enjeux, l’examen doit être prolongé par une personne compétente en sécurité applicative. Le dossier aide à préparer ce travail et à en discuter les résultats ; il ne remplace pas l’accès aux systèmes ni l’expertise nécessaire aux situations complexes.

La mise en ligne laisse enfin une décision à celui qui exploite le service. Il doit connaître les défauts corrigés, les incertitudes encore ouvertes et les personnes chargées d’intervenir. Le code s’écrit désormais avec davantage d’assistance. La responsabilité de demander des preuves, de financer les corrections et de maintenir les protections reste entière.