Защита платежей в no-code: 5 дыр, которые ИИ оставляет молча

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

Автор материала, практик из студии Hikmah Labs, описывает опыт сборки коммерческих продуктов с ИИ. Он столкнулся с тем, что модели молча пропускают критические уязвимости в платёжной части, и выработал методику, которая закрывает дыры до появления кода. Гайд ниже построен на его подходе и адаптирован для тех, кто работает с российскими платёжными сервисами.

Какие ошибки ИИ допускает в платежах?

Две ключевые проблемы, которые модель создаёт по умолчанию:

• Подмена цены. Модель размещает проверку суммы на фронтенде (на стороне браузера, а не сервера). Покупатель открывает код страницы, меняет цену со 100 на 1, платёжная система списывает рубль, товар уходит. Модель так делает, потому что реализует то, что видно в интерфейсе, а не то, что должно проверяться на сервере.

• Отсутствие вебхуков (webhook, автоматическое уведомление от платёжной системы на ваш сервер о статусе платежа). Модель подтверждает оплату по факту возврата пользователя на страницу «Спасибо». Два сценария: пользователь закрыл вкладку сразу после списания, деньги ушли, доступа нет, вы не узнали. Или человек просто открывает адрес страницы «Спасибо» напрямую и получает доступ бесплатно.

Обычное тестирование проверяет два пути: оплатил и получил, не оплатил и не получил. Атакующего интересует третий путь, которого в голове проверяющего нет.

Что понадобится

• Доступ к ИИ-модели, способной анализировать код (ChatGPT, Claude или аналоги, доступные в РФ, например YandexGPT для разбора задачи на русском)
• No-code-платформа, на которой собран продукт
• Подключённая платёжная система (ЮKassa, Robokassa, Stripe или аналог)
• Возможность открыть «чистую сессию» с моделью, то есть новый диалог без истории предыдущей разработки
• 2 часа на полный цикл проверки и настройку защиты

Пошаговая инструкция

1. Не просите код сразу. Для платежей, доступов и работы с чужими данными первый запрос к модели должен быть аналитическим, а не генерирующим. Пример промпта:

Не пиши код. Изучи документацию по интеграции [название платёжной системы],
стандарты безопасности и типовые уязвимости (особенно подмену цены
и валидацию платежа). Дай 2–3 варианта, как сделать это безопасно,
распиши плюсы и минусы каждого и скажи, что рекомендуешь и почему.

Этот шаг закрывает дыры до появления кода. Переделывать архитектуру потом, по словам автора, в десять раз дороже. Второй эффект: вы сами начинаете понимать, как устроен продукт. Модель объясняет сложные вещи простым языком, и вы выбираете решение осознанно.

1. Сделайте резервную копию перед любой работой с кодом. Автор описывает случай, когда ИИ-агент (программа, которая сама выполняет последовательность действий), настраивая мелочь на сервере, уронил рабочий сайт клиента. Спас бэкап, сделанный перед началом работ: три минуты, и сайт вернулся.

2. Атакуйте собственный продукт перед сдачей. Откройте чистую сессию, не тот диалог, в котором писался код, дайте модели доступ к результату и одну задачу:

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

Чистая сессия здесь принципиальна. Модель, которая знает, «как задумано», защищает замысел и объясняет, почему всё правильно. Модель, которая видит только код, ищет способ его обмануть. Автор описывает случай, когда именно на этом этапе был найден обход, пропущенный первым аудитом.

1. Настройте пять уровней защиты. Полностью защититься невозможно. Задача другая: сделать так, чтобы атака стоила дороже, чем то, что можно украсть.

2. Логирование всего. Каждый запрос, каждая операция. Кажется избыточным ровно до первого разбора инцидента, когда нужно понять, что именно произошло.

3. Автоматическая блокировка подозрительных IP. Боты, спамеры, аномальные паттерны обращений блокируются без вашего участия.
4. Контроль трат по каждому аккаунту. Скрипт следит за расходом: если с одного места пошло аномальное количество запросов к ИИ или баланс расходуется быстрее нормы, доступ блокируется мгновенно. Сначала стоп, потом разбор.
5. Алерты в реальном времени. На каждое подозрительное действие приходит уведомление. Узнать из логов через неделю и увидеть сейчас, это разница между потерей и предотвращением.

6. Аварийное отключение. Скрипт, который обрубает все внешние соединения. Сайт превращается в пустую страницу: ни данных, ни API. Плюс уведомление вам.

7. Перепроверьте каждую находку модели вручную. ИИ-агенты не заменяют полноценный пентест (тестирование на проникновение, когда специалист пытается взломать систему). Они не видят инфраструктуру целиком, не знают бизнес-контекста и, по словам автора, «уверенно врут, когда ничего не нашли».

Что делать с этим прямо сейчас, по ролям

Автору Дзена, который продаёт курсы или подписки. Если у вас есть страница оплаты, откройте чистую сессию с любой доступной моделью и попросите её найти способ обойти оплату. Это бесплатно и занимает 20 минут. Защита платежей начинается не с кода, а с правильного вопроса к модели.

Маркетологу и продакт-менеджеру. Проверьте, как именно ваш продукт подтверждает оплату: по возврату на страницу «Спасибо» или по вебхуку от платёжной системы. Первый вариант, это открытая дверь. Из платёжных систем, работающих в РФ: ЮKassa и Robokassa поддерживают вебхуки, документация у обоих на русском.

Предпринимателю, который собирает MVP с ИИ. Пять уровней защиты из этого гайда звучат избыточно для одного человека с ноутбуком. Но, как формулирует автор, «перестраховаться десять раз дешевле, чем один раз облажаться с деньгами клиента». Начните хотя бы с логирования и вебхуков, это два шага, которые закрывают большинство типовых атак.

Всё описанное не делает продукт неуязвимым. Оно делает его невыгодной целью, а для небольшого сервиса на российском рынке это ровно то, что нужно. Начните с чистой сессии и одного запроса «обойди мою оплату», результат, скорее всего, вас удивит.