Security checklist для MVP с платежами в 2026 году

Первый платеж прошел, счет в Stripe или ЮKassa пополнился, и тут встает вопрос: а что вообще нужно закрыть по безопасности, прежде чем звать следующих клиентов. Security checklist для MVP с платежами в 2026 году состоит из пяти зон: аутентификация, серверная проверка платежей, rate limiting, бэкапы и хранение секретов. Разберем каждую по шагам, с конкретными настройками и цифрами, а не общими словами "будьте осторожны".

Минимум для приема денег: MFA и bcrypt cost 12+ на входе, проверка подписи вебхука на сервере, лимит 5 попыток логина в минуту, бэкапы в отдельном хранилище с ежегодным тестом восстановления. По данным Verizon DBIR, 81% взломов через логин связаны со слабыми или украденными паролями, а MFA блокирует 99,9% таких попыток.

Зачем чек-лист безопасности нужен даже с пятью первыми клиентами?

Даже маленький MVP с пятью платящими пользователями хранит их карты, email и деньги. Атакующему не важен размер компании, важна дыра в коде.

Security minimum payments звучит скучно, пока не прилетит первый инцидент. 81% взломов, связанных со скомпрометированными логинами, происходят из-за слабых паролей и отсутствия MFA, показывает отчет Verizon Data Breach Investigations Report за 2025 год. Малый бизнес и MVP-стартапы при этом остаются самой удобной мишенью: у них меньше защиты и больше доверия к пользователю.

Вайбкодер обычно собирает MVP за пару дней в Cursor или Windsurf и сразу подключает Stripe. Логика продукта готова, а вот вопрос "кто может дернуть вебхук" никто не задавал. Дальше в статье, пункт за пунктом, закрываем именно эти дыры, без раздувания до полноценного enterprise security-аудита.

Как защитить регистрацию и вход от брутфорса?

Логин без rate limiting и с bcrypt cost ниже 10 открыт для перебора паролей за часы. Два простых шага, MFA и правильный cost-фактор, закрывают основную часть риска.

Логин, регистрация и восстановление пароля без лимитов на попытки, это открытое приглашение для credential stuffing. Автоматизированный скрипт способен перебрать миллионы комбинаций против одного эндпоинта за считаные часы, если ничего его не тормозит.

Три вещи закрывают 80% риска на входе. Первая: включите MFA везде, где можно, это блокирует 99,9% несанкционированных попыток входа. Вторая: если стек уже на bcrypt (как в шаблонах на next-auth и большинстве no-code бойлерплейтов), держите cost-фактор не ниже 12 и проверяйте, что логин укладывается в 250 мс. Третья: для новых проектов OWASP с 2024 года рекомендует Argon2id вместо bcrypt.

bcrypt или Argon2id для нового MVP?

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

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

Успех оплаты должен подтверждать только сервер через подпись вебхука Stripe, а не редирект на "спасибо за оплату". Иначе любой человек с адресной строкой откроет платный доступ бесплатно.

Самая частая дыра в MVP: фронт сам решает, что оплата прошла, и просто редиректит на success-страницу. Никакой проверки на бэкенде нет. Открыть платный функционал в этом случае можно вручную, просто зайдя на нужный URL.

Правильная схема простая. Stripe шлет POST-запрос на ваш вебхук с заголовком Stripe-Signature, где зашиты таймстамп и HMAC-подпись от сырого тела запроса. Сервер обязан пересчитать эту подпись с секретом из Stripe Dashboard и сравнить, прежде чем менять статус заказа. Библиотека Stripe делает это одной функцией: stripe.webhooks.constructEvent(...), важно только передавать необработанное тело запроса, а не JSON после парсинга.

Второй момент: Stripe может прислать одно и то же событие дважды из-за ретраев, поэтому обработчик обязан быть идемпотентным, то есть безопасно переживать повторный вызов по event.id. Без этого пользователь рискует получить два активированных заказа за одну оплату.

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

Ровно так и с проверкой вебхука. Она выглядит как мелочь на фоне всего продукта, но именно эта функция стоит между вами и бесплатным доступом для всех желающих.

Какие лимиты запросов поставить на API и вебхуки?

Rate limiting нужен не только для защиты от DDoS, но и против перебора паролей и повторных запросов на оплату. Разные эндпоинты требуют разных лимитов.

Один лимит на все API это плохая идея: логин ловит 1000 запросов в минуту и открыт для брутфорса, а health-check душится десятью. Разделяйте лимиты по типу эндпоинта и возвращайте статус 429 с заголовком Retry-After, чтобы легитимный клиент понимал, сколько ждать.

Для MVP на Next.js такой middleware пишется за 20-30 минут, даже без готовой библиотеки. Claude Code или Cursor сгенерируют рабочий вариант на upstash/ratelimit или express-rate-limit по короткому промпту с этой таблицей внутри.

Как делать бэкапы, чтобы не потерять базу вместе с деньгами клиентов?

Резервная копия в том же облачном аккаунте, что и рабочая база, не спасет от ransomware или случайного удаления. Копию нужно хранить отдельно и хотя бы раз проверять восстановление.

База данных с заказами, статусами оплат и email пользователей это единственный источник правды о том, кто и сколько заплатил. Потерять ее значит потерять деньги клиентов буквально, а не фигурально.

Правило простое: бэкап должен лежать в другом облачном аккаунте или tenant, недоступном той же учетной записи, что имеет доступ к продакшену. Если атакующий получит доступ к продакшн-аккаунту, у него не должно быть автоматического доступа и к бэкапам. Второе правило: восстановление нужно тестировать хотя бы раз в год, а не полагаться, что кнопка "restore" точно сработает, когда прижмет.

Для Sanity, Supabase, Postgres на Railway или аналогичного стека это обычно означает: включить автоматический экспорт по расписанию, класть архив в отдельный S3-бакет или Google Cloud Storage под отдельным аккаунтом, и раз в квартал реально разворачивать копию на тестовом окружении.

Где хранить секреты и API-ключи?

Секреты в коде, в .env в публичном репозитории или в Slack-переписке, это утечка, которая случится, вопрос только времени. Один .env.example с реальными значениями в git уже считается инцидентом.

Секреты вроде STRIPE_API_KEY, STRIPE_WEBHOOK_SECRET или токена базы данных не должны попадать в git ни разу, даже случайно в истории коммитов. Частая ошибка вайбкодеров: .env.example заполняют реальными значениями для удобства и забывают заменить на плейсхолдеры перед пушем в публичный репозиторий.

Три правила закрывают базовый риск. Первое: .env всегда в .gitignore, проверяйте это перед первым коммитом, а не после утечки. Второе: продакшен-секреты живут в переменных окружения Railway, Vercel или аналогичной платформы, не в коде и не в CI-логах. Третье: если секрет все же попал в публичный репозиторий, недостаточно удалить файл, нужно ротировать сам ключ в Stripe и других сервисах, потому что история git все еще его хранит.

Что проверить в первую неделю после первого платежа?

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

Шаг 1. Проверить логи вебхука. В Stripe Dashboard, в разделе Developers → Webhooks, видна история доставки с кодами ответа. Красные записи значат, что событие не обработалось, и заказ может зависнуть в статусе pending.

Шаг 2. Прогнать тестовый ретрай. Через Stripe CLI отправьте одно и то же событие дважды и убедитесь, что заказ не задвоился. Это самый быстрый способ поймать неидемпотентный обработчик до того, как это сделает реальный пользователь.

Шаг 3. Проверить rate limiting на логине. Откройте DevTools, отправьте 10 запросов логина подряд с неверным паролем, убедитесь, что после 5-й приходит 429, а не 200 с ошибкой в теле.

Шаг 4. Сверить .env с .gitignore. Один git log --all -- .env покажет, попадал ли файл в историю хоть раз.

Шаг 5. Запустить тестовое восстановление бэкапа. Даже вручную, на локальной машине, один раз это стоит того, чтобы знать, что архив реально рабочий.

Что закрыть сегодня, а что можно отложить на потом?

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

Секьюрити на старте это не крепость с нуля, а пять базовых процессов, закрытых по очереди. Полное соответствие GDPR, SOC2 или пентест нужны позже, когда появятся клиенты, которые их спросят.

Глоссарий

• Rate limiting это ограничение количества запросов от одного клиента за промежуток времени, защищает от брутфорса и перегрузки сервера.
• Идемпотентность обработчика это свойство кода безопасно обрабатывать одно и то же событие несколько раз без побочных эффектов.
• HMAC-подпись это способ подтвердить, что запрос действительно пришел от заявленного отправителя, через хеш с секретным ключом.
• Argon2id это алгоритм хеширования паролей, рекомендованный OWASP как основной с 2024 года, устойчив к перебору на GPU.
• Credential stuffing это атака, при которой злоумышленник массово подставляет утекшие пары логин-пароль на разных сайтах.
• Zero Trust это принцип, при котором ни один запрос не считается безопасным по умолчанию, каждый проверяется заново.

Часто задаваемые вопросы про безопасность MVP с платежами

Нужен ли пентест для MVP на старте? Нет, полноценный пентест стоит денег и времени, которых у раннего MVP обычно нет. Достаточно пяти базовых процессов из этого чек-листа: auth, серверная проверка платежей, rate limiting, бэкапы, секреты вне кода.

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

Какой rate limit ставить на логин, если не уверены в цифрах? Начните с 5 попыток за 15 минут по паре IP + email, это стандартная планка для авторизации в 2026 году. Дальше корректируйте по логам реального трафика.

Что делать, если секрет уже попал в публичный git-репозиторий? Недостаточно удалить файл из последнего коммита. Ротируйте сам ключ в Stripe, Sanity или другом сервисе, потому что старое значение навсегда останется в истории git.

Обязательно ли переходить с bcrypt на Argon2id прямо сейчас? Нет, если текущий cost-фактор bcrypt не ниже 12 и логин укладывается в 250 мс. OWASP считает bcrypt допустимым, Argon2id рекомендует только для новых проектов.

Как часто проверять, что бэкап реально восстанавливается? Минимум раз в год, а на активном MVP с платежами лучше раз в квартал. Бэкап, который никогда не тестировали на восстановление, по сути не бэкап.

Нужна ли отдельная команда безопасности для MVP? Нет. На этом этапе безопасность это чек-лист процессов, а не штатная единица. Роль нанятого специалиста по безопасности на более поздней стадии стартапа лучше отдавать человеку с опытом DevOps, который умеет говорить с командой на одном языке.

Вопрос защиты платежей стоит рассматривать вместе с выбором самого стека. В каталоге инструментов вайбкодинга собраны обзоры Cursor и Claude Code с точки зрения того, насколько удобно в них ревьюить чужой и свой код на такие дыры. Если тема ближе к DevOps-настройке инфраструктуры целиком, посмотрите подборку агентов для этой ниши.

Если чек-лист не закрывает конкретный кейс вашего MVP, например нестандартную схему с эскроу или подпиской через СБП, лучше разобрать это отдельно. Записаться на консультацию к Максиму можно здесь: t.me/maxnagovitsyn.

Обновлено: август 2026.