Sécurité du vibe coding : les problèmes que nous vérifions dans les applications générées par l'IA

La sécurité du vibe coding concerne principalement ce que les applications générées par l'IA omettent : l'autorisation côté serveur sur chaque enregistrement, les secrets conservés hors du client, les règles de base de données verrouillées, la validation des entrées, les webhooks de paiement sécurisés et les limites de débit. Examinez ces limites de confiance avant le lancement, car l'application peut sembler terminée alors que tout utilisateur connecté peut lire les données de tout le monde.

Ceci est le niveau de liste de contrôle de notre travail de prototype à production. Pour l'ordre de renforcement global, consultez comment transformer un prototype Lovable ou v0 en une application de production. Pour les agents spécifiquement, consultez les limites de la construction d'agents uniquement à partir d'outils de vibe-code. Ici, nous listons les problèmes concrets que nous recherchons dans les applications web et mobiles construites par l'IA, basés sur des modèles courants de limites de confiance et l'implémentation du portail ImadDhin. Rien ici n'est une affirmation sur les statistiques de violation.

Pourquoi les applications générées par l'IA ont des lacunes prévisibles

Les outils de codage IA sont optimisés pour produire quelque chose qui fonctionne lorsque vous l'essayez. Les propriétés de sécurité sont généralement invisibles lorsque vous essayez quelque chose. Une page qui affiche vos propres commandes semble identique, que le serveur vérifie la propriété ou renvoie simplement l'ID de commande demandé par le navigateur.

Le constructeur teste également en tant qu'utilisateur unique, généralement le propriétaire, avec un accès complet. Chaque flux fonctionne parce que rien n'est jamais refusé. Lorsqu'une erreur de permission apparaît, l'invite la plus rapide pour la faire disparaître est souvent de relâcher une règle, et l'outil s'exécute.

Le code généré hérite également de modèles de tutoriels et de modèles de démarrage, où les clés se trouvent dans la configuration client et les règles de base de données sont laissées ouvertes pour plus de commodité. Ces modèles sont corrects pour une démo et incorrects pour les clients.

Qu'est-ce que les équipes ne comprennent pas sur la sécurité du code généré par l'IA ?

La plupart des erreurs traitent la plateforme, l'interface ou l'outil d'IA lui-même comme l'examen de sécurité. Les plus courantes :

• Supposer qu'une plateforme hébergée ou un backend-as-a-service rend l'application sécurisée par défaut
• Masquer les boutons dans l'interface et traiter cela comme une autorisation
• Demander au même outil d'IA si son code est sécurisé et accepter la réponse comme un examen
• Relâcher les règles de base de données pour corriger une erreur de permission au lieu de corriger la requête
• Planifier l'examen de sécurité après le lancement

Les plateformes fournissent de bons blocs de construction, mais la configuration et la logique d'autorisation vous appartiennent. L'examen doit être effectué par quelqu'un qui recherche les défaillances, et non par l'outil qui a écrit le code.

Qu'est-ce qui figure sur une liste de contrôle de sécurité du vibe coding ?

La liste de contrôle couvre huit limites de confiance, de l'authentification aux opérations, et chaque élément nomme une limite qui doit être vérifiée délibérément. L'autorisation vient en premier pour une raison : le Contrôle d'accès défaillant est en tête du Top 10 de l'OWASP.

Authentification et comptes

• Les flux de réinitialisation de mot de passe et de vérification d'e-mail ne peuvent pas être rejoués ou ignorés
• Les URL de redirection OAuth sont restreintes aux domaines connus
• Les rôles tels qu'administrateur proviennent d'une source contrôlée par le serveur, jamais d'un champ de profil que l'utilisateur peut modifier
• Les sessions expirent et la déconnexion invalide ce qu'elle devrait

Autorisation sur chaque enregistrement

• Chaque lecture et écriture vérifie la propriété ou la location sur le serveur ou dans les règles de la base de données
• La modification d'un ID dans une requête ne peut pas renvoyer ou modifier l'enregistrement d'un autre utilisateur
• Les routes d'administration et les points de terminaison d'API sont protégés côté serveur, pas seulement masqués dans la navigation
• Les points de terminaison de liste filtrent par l'utilisateur ou le locataire actuel, pas seulement par ce que la page affiche

Règles de base de données et de stockage

• La sécurité au niveau des lignes ou des règles équivalentes sont activées sur chaque table ou collection exposée
• Aucune règle n'autorise des lectures ou des écritures illimitées par commodité
• Les règles de création valident la forme et la propriété des nouveaux enregistrements
• Les compartiments de stockage de fichiers ont leurs propres règles et n'autorisent pas la liste publique

Pour les projets Supabase, c'est un sujet à part entière, couvert dans Erreurs de sécurité au niveau des lignes Supabase dans les applications construites par l'IA.

Secrets et configuration

• Aucune clé secrète de rôle de service, d'administrateur ou de paiement dans le code client ou les variables d'environnement publiques
• Aucun secret dans les fichiers commités, y compris l'historique
• Les cartes sources de production n'exposent pas la logique ou les clés du serveur
• CORS est restreint et les en-têtes de sécurité sont définis

Entrée, sortie et fonctionnalités d'IA

• Validation côté serveur sur chaque entrée, pas seulement dans le formulaire
• Le contenu utilisateur rendu en Markdown ou HTML est nettoyé
• Les téléchargements de fichiers vérifient le type et la taille et sont stockés en dehors de la racine web
• Les fonctionnalités qui récupèrent des URL ne peuvent pas atteindre les adresses réseau internes, le risque classique de falsification de requête côté serveur
• La sortie du modèle est traitée comme non fiable et ne peut pas déclencher d'actions sans vérifications
• Les clés du fournisseur de modèle sont utilisées uniquement sur le serveur

Paiements et droits

• Les prix et les identifiants de plan sont définis sur le serveur, jamais pris du client
• Les signatures de webhook sont vérifiées avant tout traitement
• Les gestionnaires de webhook sont idempotents, de sorte qu'un événement réessayé n'accorde pas l'accès deux fois
• L'accès est accordé à partir de l'événement de paiement vérifié, et non en atteignant une page de succès

Abus et coût

• Limites de débit sur la connexion, l'inscription, la réinitialisation de mot de passe et les points de terminaison d'IA
• Les compteurs de quota et de crédit sont mis à jour atomiquement
• Les formulaires publics ont une protection contre les bots proportionnelle à leur risque

Dépendances et opérations

• Chaque package ajouté existe, est celui prévu et est maintenu
• Les routes de débogage, les points de terminaison d'amorçage et les comptes de test sont supprimés
• Les erreurs affichées aux utilisateurs n'incluent pas les traces de pile ou les requêtes
• Les événements pertinents pour la sécurité, tels que les connexions, les changements de rôle et les actions d'administration, sont enregistrés sans secrets ni données personnelles inutiles

Comment effectuer un examen de sécurité sur une application construite par l'IA ?

Exécutez-le en quatre étapes : un court modèle de menace, des tests externes, des corrections classées par rayon d'explosion et des vérifications automatisées qui maintiennent les corrections en place. Commencez par le modèle de menace : quelles données l'application contient, qui devrait les voir, ce qu'un attaquant voudrait et quelles actions coûtent de l'argent. Une heure de cela concentre le reste de l'examen.

Ensuite, testez comme un étranger. Créez deux comptes ordinaires et essayez de lire, modifier et supprimer les données de l'autre via l'interface et directement via l'API. Interrogez la base de données avec la clé client publique en étant déconnecté. Recherchez dans le bundle client construit tout ce qui ressemble à une clé. Rejouez un webhook de paiement. Envoyez la même requête plusieurs fois rapidement. Ces tests trouvent plus de problèmes réels que la simple lecture du code.

Corrigez par ordre de rayon d'explosion : les secrets exposés et les règles de base de données ouvertes en premier, car ils affectent tous les utilisateurs à la fois ; puis les lacunes d'autorisation ; puis les paiements ; puis les limites d'abus et le renforcement. Faites pivoter tout secret qui a été exposé, même brièvement, plutôt que de le supprimer uniquement du code.

Enfin, assurez-vous que les corrections restent en place. Ajoutez les tests inter-comptes à votre suite automatisée, mettez les fichiers de règles sous examen et ajoutez l'analyse des secrets au référentiel, afin que la prochaine modification générée par l'IA ne puisse pas rouvrir discrètement les mêmes failles.

Ce que coûte un examen de sécurité et quand être plus léger

Un examen coûte quelques jours avant le lancement et certaines fonctionnalités qui dépendaient d'un accès ouvert, et sa profondeur doit correspondre aux données et à l'argent impliqués. Des règles de base de données strictes cassent parfois des fonctionnalités qui dépendaient d'un accès ouvert. Cette rupture est utile : elle montre quelles requêtes s'appuyaient sur la faille. Corriger la requête est plus de travail que de restaurer la règle ouverte, et c'est la seule correction qui tient.

Un examen approfondi ralentit le lancement de jours, pas de mois, pour la plupart des prototypes. L'alternative est de découvrir les mêmes problèmes après que les clients ont fait confiance à l'application avec leurs données, lorsque les corrections nécessitent également une notification, une rotation et un nettoyage.

Toutes les découvertes ne justifient pas le même effort. Un prototype utilisé en interne avec des données de test a besoin de moins qu'une application publique qui accepte les paiements. Adaptez la profondeur de l'examen aux données et à l'argent impliqués.

Modèles que nous observons dans nos propres règles et dans les revues de code

Ce sont des observations au niveau du code de la configuration du portail ImadDhin et des vérifications d'examen proposées, et non des affirmations sur des incidents clients.

Les règles de base de données du portail refusent l'accès par défaut, sans règle fourre-tout. Les sessions de chat, les messages, la mémoire sauvegardée et les enregistrements d'utilisation sont entièrement refusés aux clients et gérés uniquement par les routes du serveur. Plusieurs collections d'admission publiques autorisent la création mais pas la lecture, la mise à jour ou la suppression, avec des fonctions de validation vérifiant la forme de chaque nouvel enregistrement.

Un modèle d'échec instructif est une règle d'admission qui accepte toute création parce qu'un serveur écrit dans cette collection via le SDK client. Les règles de base de données ne peuvent pas distinguer un serveur utilisant le SDK client d'un navigateur, donc une règle écrite pour laisser entrer le serveur laisse entrer tout le monde. Traitez ce modèle comme une découverte : écrivez depuis le serveur avec des identifiants administratifs et refusez les écritures client, ou ajoutez la même validation de forme que les autres collections utilisent.

Les compteurs d'utilisation sont le deuxième modèle. Un compteur qui lit le nombre actuel puis écrit la valeur incrémentée en une étape distincte, en dehors d'une transaction, permet à deux requêtes concurrentes de passer le contrôle de limite. Pour une petite allocation gratuite, l'exposition est mineure, mais le même modèle protégeant un solde de crédit payant est une véritable vulnérabilité, et c'est exactement le genre de code qui passe un examen rapide.

Les secrets du serveur sont résolus au moment de l'exécution sur le serveur, d'abord à partir de la configuration de l'environnement, puis d'un gestionnaire de secrets, et aucun n'utilise un préfixe public. Les règles d'ignorance de déploiement sont un filet de sécurité utile, mais l'habitude la plus forte est de conserver les fichiers d'informations d'identification entièrement en dehors du référentiel, de sorte qu'une seule règle mal configurée ne puisse pas les exposer.

Quels tests trouvent des lacunes de sécurité dans une application construite par l'IA ?

• Connectez-vous en tant qu'utilisateur B et demandez les enregistrements de l'utilisateur A par ID via l'API
• Interrogez chaque table ou collection avec la clé client publique en étant déconnecté
• Recherchez dans le bundle de production et les cartes sources des chaînes ressemblant à des secrets
• Rejouez un webhook de paiement et confirmez que l'accès n'est accordé qu'une seule fois
• Modifiez votre propre profil pour ajouter un rôle d'administrateur et vérifiez que cela n'a aucun effet
• Envoyez des requêtes parallèles à une limite de quota et confirmez qu'elle est respectée
• Collez une balise de script dans un champ de texte qui est rendu ailleurs

Quand une configuration de sécurité plus légère est-elle suffisante ?

Si l'application est un prototype interne avec des données factices, la mesure de sécurité la plus simple est de ne pas l'exposer publiquement : gardez-la derrière une authentification ou un réseau privé jusqu'à ce qu'elle soit prête pour de vraies données.

Si l'application n'a besoin que d'une connexion et de quelques pages, utilisez l'authentification gérée de votre plateforme et les règles par défaut les plus restrictives, et évitez les rôles personnalisés jusqu'à ce que vous en ayez besoin. Moins de fonctionnalités signifient moins de limites de confiance à examiner. Parfois, la meilleure correction de sécurité est de supprimer une fonctionnalité que personne n'utilise.

Faites l'examen avant que les clients ne trouvent les lacunes

Exécutez la liste de contrôle, testez avec deux comptes et un client déconnecté, et corrigez par rayon d'explosion. Si vous préférez que l'examen et les corrections soient effectués pour vous, consultez la pratique de sauvetage de vibe-code d'ImadDhin, envoyez les détails de votre référentiel via le brief de projet, ou réservez un appel de 30 minutes.

Comment explorer les risques de cybersécurité avant une évaluation ?

Le laboratoire interactif de cybersécurité utilise des requêtes synthétiques pour illustrer la manipulation de la caisse, les événements de paiement falsifiés, l'isolation des locataires, les secrets exposés et les approbations d'outils d'IA. Déclenchez une défaillance, activez une protection et rejouez le même événement avant d'activer le reste. Protéger un prix n'établit pas la propriété de la commande, et déplacer une clé vers le serveur ne révoque pas une copie exposée.

Xion dans la vitrine de cybersécurité est une démonstration conceptuelle des décisions d'autorisation, de blocage et d'approbation. Il ne surveille ni ne protège votre application. Pour votre plateforme, les preuves doivent provenir de tests ciblés de l'autorisation réelle, du paiement et des limites de données. Utilisez le labo pour identifier les questions d'examen, puis vérifiez l'implémentation dans l'environnement pertinent.