Sécurité des paiements et vibe coding : les deux failles que l'IA laisse passer à chaque fois

Habr a publié un article pratique sur la sécurité des paiements dans les produits développés avec l'aide de l'IA. Son auteur, un vibe coder sans expérience professionnelle du développement, y analyse deux vulnérabilités que le code généré par les réseaux de neurones reproduit à coup sûr, et décrit cinq niveaux de protection auxquels il est parvenu par sa propre expérience.

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

La thèse centrale de l'article : le réseau de neurones n'écrit pas du mauvais code, il écrit du code qui a l'air de fonctionner. La nuance est essentielle. Le scénario de base marche : l'utilisateur clique sur « payer », l'argent arrive, le test passe au vert. La vulnérabilité reste invisible jusqu'au moment où un attaquant la trouve, et non le développeur.

« L'erreur la plus coûteuse dans ce travail n'est pas que le réseau de neurones écrive du mauvais code, mais qu'il écrive du code qui a l'air de fonctionner », écrit l'auteur dans son article sur

Habr.

C'est pourquoi le module de paiement constitue une zone de risque à part : une erreur cachée n'y entraîne pas le plantage de l'application, mais des pertes financières directes, pour le produit ou pour ses utilisateurs.

Deux failles que le réseau de neurones reproduit systématiquement

L'auteur identifie deux défaillances propres au code de paiement généré par l'IA :

• Falsification du prix : le serveur accepte le montant contenu dans le corps de la requête du client, sans le comparer au prix réel stocké en base. Un attaquant modifie la valeur dans les DevTools et paie le produit la somme qu'il veut, y compris 1 rouble.
• Absence de vérification des webhooks : le serveur accepte les notifications de paiement sans contrôler la signature du système de paiement. Il devient alors possible d'envoyer une fausse confirmation de transaction et d'accéder au produit sans aucun paiement réel.
• Les assistants IA reproduisent régulièrement ces deux schémas : dans les données d'entraînement, de telles vérifications passent souvent pour des « détails d'implémentation » et sont omises.

Selon l'auteur, le réseau de neurones ne comble automatiquement aucune de ces deux vulnérabilités : il faut le demander explicitement ou vérifier à la main après la génération du code.

Comment tester son produit avant la mise en production

L'auteur décrit une méthode précise : avant la livraison, ouvrir le produit en navigation privée, sans jetons, cookies ni authentification enregistrés, et tenter de réaliser un paiement avec des paramètres de requête modifiés. L'objectif est de simuler les actions d'un attaquant tant qu'il reste du temps pour corriger le code.

Pour un vibe coder sans équipe ni revue de code, cette méthode remplace à la fois l'audit de sécurité et les tests : le seul vrai rempart est son propre regard, placé du côté de l'attaquant.

Cinq niveaux de protection

L'article décrit cinq niveaux de protection du module de paiement que l'auteur a élaborés en pratique. Selon lui, l'IA les omet tous les cinq lors de la première génération : sans demande explicite dans le prompt ou vérification manuelle, ils n'apparaîtront pas dans le code. Le détail de chaque niveau figure dans le texte complet : d'après 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 intégrant des paiements. L'IA génère avec assurance la logique de base des flux, mais omet systématiquement la protection à la jonction du client et du serveur. Ceux qui construisent des produits avec des réseaux de neurones ont besoin d'une checklist explicite pour les points critiques, sous peine d'apprendre la leçon, très coûteuse, en production.

Questions fréquentes

Quelles vulnérabilités le réseau de neurones laisse-t-il passer dans

le code de paiement ?

D'après l'auteur de l'article sur Habr, deux schémas sont systématiquement omis : la falsification du montant du paiement côté client (le serveur accepte le prix de la requête sans le comparer à la base) et l'absence de vérification de la signature du webhook du système de paiement. Les deux permettent de valider 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 méthode de la session vierge : ouvrir le produit en navigation privée, sans authentification, et tenter de réaliser un paiement avec des paramètres modifiés. Cela simule les actions d'un attaquant et permet de repérer la vulnérabilité avant la mise en production, sans équipe ni revue de code.