Просишь ассистента «сделай приём платежей» — и получаешь код, который работает. Нажал кнопку, оплатил, получил доступ. Тесты проходят, демо клиенту показывается.

Дальше кто-то открывает devtools и платит доллар вместо ста.

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

Дыра первая: цена приходит с клиента

Вот что генерируется по умолчанию:

// так делать нельзя
app.post('/checkout', async (req, res) => {
  const { productId, amount } = req.body;        // ← сумма пришла из браузера
  const session = await psp.createSession({ amount, currency: 'usd' });
  res.json({ url: session.url });
});

Формально всё логично: фронтенд знает цену, он её и передал. Но фронтенд — это то, что лежит на машине покупателя, и правится он в одну строку в консоли. amount: 10000 превращается в amount: 100, платёжка честно списывает доллар, товар уходит.

Правильно — клиент присылает только идентификатор того, что покупает. Цену сервер берёт у себя:

app.post('/checkout', requireAuth, async (req, res) => {
  const product = await products.get(req.body.product_id);
  if (!product) return res.sendStatus(404);

  // заказ фиксируем до похода в платёжку: с ним потом будем сверять вебхук
  const order = await orders.create({
    user_id:      req.user.id,
    product_id:   product.id,
    amount_cents: product.price_cents,   // цена только из базы
    currency:     product.currency,
    status:       'pending',
  });

  const session = await psp.createSession({
    amount:   order.amount_cents,
    currency: order.currency,
    metadata: { order_id: order.id },
  });

  res.json({ url: session.url });
});

Разница в три строки. Но пока сумма приходит из req.body, любые проверки выше по коду бессмысленны.

Дыра вторая: оплата подтверждается страницей «Спасибо»

Второй типовой вариант: пользователь возвращается с платёжки на /success, и доступ выдаётся прямо там.

Это ломается в обе стороны. Человек закрыл вкладку сразу после списания — деньги ушли, доступа нет, вы об оплате не узнали. Или наоборот: открыл /success напрямую, минуя оплату, и получил доступ бесплатно.

Единственный источник правды об оплате — вебхук от провайдера. И его мало принять, его надо проверить:

const crypto = require('crypto');

// express.raw — принципиально: подпись считается от сырого тела.
// После JSON.parse и повторной сериализации байты уже другие.
app.post('/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  const sig = req.get('X-Signature');
  const ts  = req.get('X-Timestamp');
  if (!sig || !ts) return res.sendStatus(400);

  // 1. Replay: перехваченный когда-то валидный вебхук нельзя переиграть завтра
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return res.sendStatus(400);

  const expected = crypto
    .createHmac('sha256', process.env.WEBHOOK_SECRET)
    .update(`${ts}.${req.body}`)
    .digest('hex');

  // 2. Сравнение за постоянное время. Обычное === утекает по таймингу:
  //    по скорости отказа подпись подбирается побайтово.
  const ok = sig.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected));
  if (!ok) return res.sendStatus(403);

  const event = JSON.parse(req.body);

  // 3. Идемпотентность: провайдер шлёт повтор, пока не получит 200.
  //    Без этой проверки одна оплата продлевает подписку трижды.
  if (await events.exists(event.id)) return res.sendStatus(200);

  // 4. Сумму сверяем со своим заказом, а не доверяем событию
  const order = await orders.get(event.metadata.order_id);
  if (!order ||
      order.amount_cents !== event.amount_cents ||
      order.currency     !== event.currency) {
    await alerts.send('payment_mismatch', { event });
    return res.sendStatus(409);
  }

  await events.save(event.id);
  await orders.markPaid(order.id);
  res.sendStatus(200);
});

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

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

Почему модель делает именно так

Я не Senior-программист, я собираю продукты с помощью ИИ — и первое, чему это научило: опаснее всего не плохой код, а код, который выглядит рабочим.

Модель воспроизводит самый частый паттерн из того, на чём училась. А в туториалах и примерах проверка почти всегда на клиенте: так короче и нагляднее. Она реализует то, что видно в интерфейсе, потому что интерфейс — это то, что вы ей описали.

Поэтому для критичных фич — платежи, доступы, чужие данные — первый запрос у меня не про код:

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

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

На каждую кнопку так делать не нужно. На платежи — обязательно.

Атака на собственный продукт перед сдачей

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

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

В тот раз они нашли обход, который пропустил первый аудит.

Отдельно про бэкапы: привычка появилась после дня, когда ИИ-агент, настраивая мелочь на сервере, уронил рабочий сайт клиента. Спасла копия, снятая перед началом работ, — три минуты, и сайт вернулся. С тех пор бэкап у меня первый шаг любой задачи.

Что стоит вокруг платежей

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

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

// Считаем не только запросы, но и деньги: 10 дорогих запросов
// бьют по кошельку сильнее, чем 1000 дешёвых.
async function guard(accountId, costCents) {
  const WINDOW = 3600;
  const now = Math.floor(Date.now() / 1000);
  const key = `spend:${accountId}`;

  await redis.zremrangebyscore(key, 0, now - WINDOW);
  await redis.zadd(key, now, `${now}:${crypto.randomUUID()}:${costCents}`);
  await redis.expire(key, WINDOW);

  const entries  = await redis.zrange(key, 0, -1);
  const requests = entries.length;
  const spent    = entries.reduce((s, e) => s + Number(e.split(':')[2]), 0);

  const limit = await limits.get(accountId);
  if (requests > limit.requests_per_hour || spent > limit.cents_per_hour) {
    await accounts.block(accountId, 'anomaly');
    await alerts.send('account_blocked', { accountId, requests, spent });
    return false;
  }
  return true;
}

Срабатывает это в двух случаях: либо человек нашёл уязвимость, либо кто-то посторонний гоняет запросы к платному ИИ-API за мой счёт — нашёл эндпоинт, который проксирует запросы в модель в обход интерфейса и лимитов, и пользуется им как бесплатным ChatGPT. В обоих случаях сначала стоп, потом разбор.

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

Звучит пафосно для продукта, который делает один человек. Но перестраховаться десять раз дешевле, чем один раз облажаться с деньгами клиента.

Честная часть

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

И код выше не делает продукт неуязвимым. Он закрывает два конкретных места, в которых ошибаются чаще всего.

Две дыры в приёме платежей, которые ИИ-ассистент оставляет по умолчанию