Платёжная безопасность при вибкодинге: две уязвимости, которые ИИ пропускает всегда

Sur Habr a été publié un article pratique sur la sécurité des paiements dans les produits construits avec l'IA : l'auteur — un vibe coder sans expérience professionnelle en développement — a analysé deux vulnérabilités que le code des réseaux neuronaux reproduit systématiquement et a décrit cinq niveaux de protection auxquels il est parvenu par sa propre expérience.

Pourquoi le code IA dans les paiements est plus dangereux qu'un bug évident

La thèse clé de l'article : un réseau neuronal n'écrit pas du mauvais code — il écrit du code qui semble fonctionner. C'est une différence fondamentale. Le scénario de base fonctionne : l'utilisateur clique sur « payer », l'argent arrive, le test est vert. La vulnérabilité reste invisible jusqu'à ce qu'un acteur malveillant la trouve — et non le développeur.

«

La faute la plus coûteuse dans ce type de travail n'est pas que le réseau neuronal écrit du mauvais code, mais qu'il écrit du code qui semble fonctionner », écrit l'auteur dans l'article Habr.

C'est précisément pourquoi le module de paiement est une zone de risque particulière : une erreur cachée ici ne signifie pas la chute de l'application, mais des pertes financières directes — pour le produit ou pour les utilisateurs.

Deux failles que le réseau neuronal reproduit systématiquement

L'auteur identifie deux défaillances caractéristiques spécifiquement du code de paiement généré par IA :

• Substitution de prix — le serveur accepte le montant du corps de la requête client sans le comparer au prix réel dans la base de données. Un acteur malveillant modifie la valeur dans DevTools et paye le produit pour n'importe quel montant arbitraire — même 1 rouble.
• Absence de vérification des webhooks — le serveur accepte les notifications de paiement sans vérifier la signature du système de paiement. Cela permet d'envoyer une fausse confirmation de transaction et d'obtenir l'accès au produit sans paiement réel.
• Les deux patterns sont reproduits régulièrement par les assistants IA : dans les données d'entraînement, ces vérifications apparaissent souvent comme des « détails d'implémentation » et sont omises.

Selon l'auteur, aucune de ces vulnérabilités n'est fermée automatiquement par le réseau neuronal — il faut les demander explicitement ou les vérifier manuellement après la génération du code.

Comment vérifier le produit avant la mise en production

L'auteur décrit une technique concrète : avant de livrer, ouvrir le produit en mode navigation privée — sans tokens sauvegardés, cookies ni autorisation — et essayer d'effectuer un paiement avec des paramètres de requête modifiés. L'objectif est de simuler les actions d'un attaquant pendant qu'il est encore temps de corriger le code.

Pour un vibe coder sans équipe ni code review, cette technique remplace à la fois l'audit de sécurité et les tests : la seule barrière réelle est son propre regard du point de vue de l'attaquant.

Cinq niveaux de protection

L'article décrit cinq niveaux de protection du module de paiement que l'auteur a développés en pratique. Selon lui, les cinq sont omis par l'IA lors de la première génération — sans une demande explicite dans le prompt ou une vérification manuelle, ils ne figureront pas dans le code. Les détails de chaque niveau sont dans le texte complet : selon l'article, ils couvrent la validation côté serveur des données entrantes, la protection contre les requêtes répétées et l'audit des événements de paiement.

Ce que cela signifie

Le vibe coding a abaissé le seuil d'entrée dans le développement, mais n'a pas modifié les exigences de sécurité que le monde réel impose aux produits avec paiements. L'IA génère avec confiance la logique de base des flux, mais omet systématiquement la protection à la frontière client-serveur. Ceux qui construisent des produits avec des réseaux neuronaux ont besoin d'une liste de contrôle explicite pour les points critiques — ou d'une leçon coûteuse en production.

Questions fréquentes

Quelles vulnérabilités le réseau neuronal omet-il dans le code de paiement ?

Selon l'auteur de l'article sur Habr, deux patterns sont systématiquement omis : la substitution du montant du paiement côté client (le serveur accepte le prix de la requête sans le vérifier dans la base de données) et l'absence de vérification de la signature du webhook du système de paiement. Les deux permettent d'effectuer une transaction sans paiement réel.

Comment un vibe coder peut-il vérifier la sécurité des paiements avant

la mise en production ?

L'auteur recommande la technique de session propre : ouvrir le produit en mode navigation privée sans autorisation et essayer d'effectuer un paiement avec des paramètres modifiés. Cela simule les actions d'un attaquant et permet d'identifier les vulnérabilités avant le déploiement en production — sans équipe ni code review.