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

On Habr, a practical article was published about payment security in AI-built products: the author — a vibe coder without professional development experience — analyzed two vulnerabilities that neural network code reproduces consistently, and described five levels of protection he arrived at through his own experience.

Why AI code in payments is more dangerous than an obvious bug

The article's key thesis: a neural network doesn't write bad code — it writes code that looks working. This is a fundamental difference. The basic scenario works: the user clicks "pay," the money arrives, the test is green. The vulnerability remains invisible until a malicious actor finds it — not a developer.

"The most expensive mistake in this kind of work isn't that the neural network writes bad code, but that it writes code that looks working," the author writes in the

Habr article.

This is precisely why the payment module is a special risk zone: a hidden error here doesn't mean an application crash — it means direct financial losses, for the product or for users.

Two holes the neural network reproduces systematically

The author identifies two failures characteristic specifically of AI-generated payment code:

• Price substitution — the server accepts the amount from the client request body without checking it against the actual price in the database. A malicious actor changes the value in DevTools and pays for a product at any arbitrary amount — even 1 ruble.
• Absence of webhook verification — the server accepts payment notifications without verifying the signature from the payment system. This allows sending a fake transaction confirmation and gaining access to the product without a real payment.
• Both patterns are reproduced regularly by AI assistants: in training data, such checks often appear as "implementation details" and are omitted.

According to the author, neither of these vulnerabilities is closed automatically by the neural network — they must be requested explicitly or checked manually after code generation.

How to check the product before release

The author describes a concrete technique: before submitting, open the product in incognito mode — without saved tokens, cookies, or authorization — and try to process a payment with modified request parameters. The goal is to simulate an attacker's actions while there is still time to fix the code.

For a vibe coder without a team or code review, this technique replaces both a security audit and testing: the only real barrier is one's own perspective from the attacker's point of view.

Five levels of protection

The article describes five levels of payment module protection that the author developed in practice. According to him, all five are skipped by AI on the first generation — without an explicit prompt request or manual review, they will not appear in the code. Details of each level are in the full text: according to the article, they cover server-side validation of incoming data, protection against replay attacks, and auditing of payment events.

What this means

Vibe coding has lowered the barrier to entry in development, but has not changed the security requirements that the real world places on products with payments. AI confidently generates the basic logic of flows, but systematically misses protection at the client-server boundary. Those building products with neural networks need an explicit checklist for critical points — or an expensive lesson in production.

Frequently Asked Questions

What vulnerabilities does the neural network miss in payment code?

According to the author of the Habr article, two patterns are systematically missed: substitution of the payment amount on the client side (the server accepts the price from the request without checking against the database) and the absence of webhook signature verification from the payment system. Both allow a transaction to be carried out without a real payment.

How can a vibe coder check payment security before release?

The author recommends a clean session technique: open the product in incognito mode without authorization and try to process a payment with modified parameters. This simulates an attacker's actions and allows vulnerabilities to be identified before going to production — without a team or code review.