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

На Хабре вышла практическая статья о платёжной безопасности в продуктах, собранных с помощью ИИ: автор — вибкодер без профессионального опыта разработки — разобрал две уязвимости, которые нейросетевой код воспроизводит гарантированно, и описал пять уровней защиты, до которых дошёл на собственном опыте.

Почему ИИ-код в платежах опаснее явного бага

Ключевой тезис статьи: нейросеть пишет не плохой код — она пишет код, который выглядит рабочим. Это принципиальная разница. Базовый сценарий работает: пользователь кликает «оплатить», деньги приходят, тест зелёный. Уязвимость остаётся невидимой ровно до тех пор, пока её не найдёт злоумышленник — а не разработчик.

«Самый дорогой факап в такой работе не в том, что нейросеть пишет плохой код, а в том, что она пишет код, который выглядит рабочим», — пишет автор в статье на

Хабре.

Именно поэтому платёжный модуль — особая зона риска: скрытая ошибка здесь означает не падение приложения, а прямые финансовые потери — продукта или пользователей.

Две дыры, которые нейросеть воспроизводит системно

Автор выделяет два провала, характерных именно для ИИ-сгенерированного платёжного кода:

• Подмена цены — сервер принимает сумму из тела клиентского запроса, не сверяя с реальной ценой в базе. Злоумышленник меняет значение в DevTools и оплачивает товар за произвольную сумму — хоть за 1 рубль.
• Отсутствие верификации вебхуков — сервер принимает уведомления об оплате без проверки подписи от платёжной системы. Это позволяет отправить фиктивное подтверждение транзакции и получить доступ к продукту без реального платежа.
• Оба паттерна ИИ-ассистенты воспроизводят регулярно: в обучающих данных такие проверки часто выглядят как «детали реализации» и опускаются.

По словам автора, ни одну из этих уязвимостей нейросеть не закрывает автоматически — нужно запрашивать явно или проверять вручную после генерации кода.

Как проверить продукт перед релизом

Автор описывает конкретный приём: перед сдачей открыть продукт в режиме инкогнито — без сохранённых токенов, куков и авторизации — и попробовать провести платёж с изменёнными параметрами запроса. Цель — имитировать действия злоумышленника, пока ещё есть время исправить код.

Для вибкодера без команды и code review этот приём заменяет сразу и аудит безопасности, и тестирование: единственный реальный заслон — собственный взгляд со стороны атакующего.

Пять уровней защиты

В статье описаны пять уровней защиты платёжного модуля, которые автор выработал на практике. По его словам, все пять ИИ пропускает при первой генерации — без явного запроса в промпте или ручной проверки их в коде не будет. Детали каждого уровня — в полном тексте: согласно статье, они покрывают серверную валидацию входящих данных, защиту от повторных запросов и аудит платёжных событий.

Что это значит

Вибкодинг снизил порог входа в разработку, но не изменил требований безопасности, которые реальный мир предъявляет к продуктам с платежами. ИИ уверенно генерирует базовую логику потоков, но системно пропускает защиту на стыке клиента и сервера. Тем, кто строит продукты с нейросетями, нужен явный чеклист для критических точек — или дорогостоящий урок на продакшне.

Частые вопросы

Какие уязвимости нейросеть пропускает в платёжном коде?

По данным автора статьи на Хабре, систематически пропускаются два паттерна: подмена суммы платежа на стороне клиента (сервер принимает цену из запроса без сверки с базой) и отсутствие проверки подписи вебхука от платёжной системы. Оба позволяют провести транзакцию без реальной оплаты.

Как вибкодеру проверить безопасность платежей перед релизом?

Автор рекомендует приём с чистой сессией: открыть продукт в инкогнито-режиме без авторизации и попробовать провести платёж с изменёнными параметрами. Это имитирует действия злоумышленника и позволяет выявить уязвимость до выхода в продакшн — без команды и code review.