Чеклист безопасности вайбкодинга 20 пунктов перед деплоем 2026

Безопасность вайбкодинга это не про программирование, а про 20 конкретных проверок, которые занимают вечер и спасают от утечки данных, слитого бюджета на API и взломанной базы. Ниже рабочий чеклист по пяти блокам: секреты, авторизация, инпуты, зависимости, логи. Разберем каждый пункт и дадим готовый промпт для автоматического аудита проекта в Claude Code или Codex.

Чеклист закрывает пять зон риска вайбкодинг-проекта: секреты и переменные окружения, авторизация и RLS, пользовательский ввод и лимиты, зависимости и AI-код, логи и мониторинг. 20 пунктов, таблица для самопроверки и готовый промпт для аудита в конце статьи.

Почему вайбкодинг-проекты чаще ломают на безопасности?

Дело не в том, что AI пишет плохой код. Дело в том, что его никто не проверяет перед публикацией, а по умолчанию AI выбирает небезопасный вариант почти в половине случаев.

Veracode в отчете 2025 года протестировала более 100 языковых моделей на 80 задачах: код с уязвимостями получался в 45% случаев. Похожая картина у GitHub Copilot: исследователи NYU Tandon прогнали 89 сценариев, получили 1692 программы, и около 40% из них содержали баги или изъяны, которыми может воспользоваться атакующий.

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

Для вайбкодинг-проекта это особенно больно. Один автор в разборе безопасности признался: сделал калькулятор калорий на Supabase, был уверен в правильной настройке RLS, даже прогнал Claude Code и Cursor для проверки, и все равно словил дыру, потому что статус подписки и лимиты запросов хранились в одной таблице с пользовательскими данными. Итог: пользователи меняли себе премиум-доступ и жгли AI-эндпоинт без ограничений.

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

С безопасностью тот же принцип. Быстро задеплоить продукт не равно закрыть глаза на 20 пунктов ниже.

Что проверить в секретах и переменных окружения?

Секреты, самая частая дыра в вайбкодинг-проектах: ключи в .env-файле, который случайно закоммитили, или API-ключ прямо во фронтенде.

Хардкод-ключи в мобильном приложении или на клиенте можно достать за пару минут через дебаг-инструменты браузера. Даже если ключ лежит в переменной окружения, на фронтенде она не защищена: любая NEXT_PUBLIC- или VITE-переменная попадает в собранный бандл и читается открыто.

1. Проверьте .env и .env.example на реальные значения

.env.example должен содержать только плейсхолдеры вида your_key_here. Если там лежат боевые токены, это первое, что нужно вычистить перед публикацией репозитория.

2. Уберите API-ключи с фронтенда

Любой запрос к платежке, AI-провайдеру или email-сервису должен идти через бэкенд. Ключ, вызванный напрямую из клиента, можно перехватить и использовать за ваш счет, именно так один разработчик получил счет на $30 000 после утечки AWS-ключа с избыточными правами.

3. Ротация ключей после каждой утечки

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

4. Проверьте git-историю на старые секреты

Удаление .env из репозитория не удаляет его из истории коммитов. Секрет, закоммиченный полгода назад, все еще читается через git log, если историю не переписать отдельно.

Как настроить RLS и авторизацию без дыр?

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

Row Level Security в Supabase работает как фильтр поверх прямого доступа фронтенда к базе. По официальной документации Supabase, RLS обязательно должен быть включен на любой таблице в открытой схеме, по умолчанию это public, иначе любой человек с anon-ключом читает и пишет что угодно. Проблема в том, что «технически правильная» RLS-политика не спасает, если рядом лежат чувствительные поля.

5. Проверяйте RLS конкретными сценариями

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

6. Не храните лимиты и подписку в одной таблице с редактируемыми данными

Если пользователь может писать в таблицу профиля, а туда же записан план подписки, он теоретически может отредактировать себе премиум-доступ через тот же RLS-разрешенный запрос. Разносите чувствительные поля в отдельную таблицу с более строгими правилами.

7. Все чувствительные вызовы идут только с бэкенда

Stripe, SendGrid, S3, AI-провайдеры, вызывайте не с фронта. Иначе кто-то перехватит эндпоинт, поменяет цену перед отправкой или начнет слать письма от вашего имени.

8. Проверка владельца объекта (IDOR)

Классическая ошибка: эндпоинт /api/order/123 отдает заказ по ID без проверки, что заказ принадлежит текущему юзеру. Меняешь цифру в адресе, видишь чужие данные. Проверяйте владельца в каждом запросе к чужому объекту.

9. Роли и права разделены явно

Admin-функции не должны быть доступны просто по факту авторизации. Прописывайте проверку роли на каждом административном действии, а не полагайтесь на скрытие кнопки в интерфейсе.

Что делать с пользовательским вводом и лимитами запросов?

Фронтенд-лимиты не работают: любой, кто найдет эндпоинт в сетевой вкладке браузера, обходит ограничения интерфейса напрямую.

Обычная логика новичка: поставить лимит «5 генераций в день» в компоненте формы. Но бэкенд-эндпоинт открыт для прямых запросов, и найти его не сложнее, чем открыть DevTools. Это касается и мобильных приложений, трафик перехватывается без особых усилий даже без видимой сетевой вкладки.

10. Валидация и санитизация входных данных

Любое поле, которое пользователь заполняет сам, обрабатывайте как потенциально вредоносное: экранируйте вывод, проверяйте типы и длину, используйте параметризованные запросы вместо конкатенации строк в SQL.

11. Рейт-лимит на бэкенде, не только на клиенте

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

12. Добавьте IP-based рейт-лимит

Пользовательские лимиты ловят одного аккаунта-нарушителя, но не спасают от массового создания аккаунтов. IP-лимит, вторая линия защиты, которую тоже реально настроить одним промптом в Cursor или Claude Code.

13. Budget caps у AI и облачных провайдеров

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

Как проверить зависимости и AI-сгенерированный код?

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

В независимой репликации исследования Copilot около 40% вариантов кода на всех языках оказались уязвимы, а более свежие тесты показывают похожую картину и на новых моделях. Дело не в конкретном инструменте, дело в привычке проверять сгенерированный код так же строго, как код джуна на испытательном сроке.

14. Гоняйте security-аудит несколько раз

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

15. Проверяйте зависимости на «галлюцинированные» пакеты

Модель иногда предлагает установить пакет, которого не существует или который зарегистрирован недавно неизвестным автором. Перед npm install или pip install проверяйте, что пакет реальный и у него есть история.

16. Не давайте AI одобрять свой же код

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

Какие логи и мониторинг нужны перед публикацией?

Без логов вы узнаете о взломе из счета за API или жалобы пользователя, а не из системы мониторинга.

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

17. Логируйте доступ к чувствительным операциям

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

18. Настройте алерты на аномальную активность

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

19. Протестируйте продукт как злоумышленник

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

20. Финальный прогон чеклиста перед публикацией

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

Таблица чеклиста безопасности вайбкодинга по категориям

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

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

В одном из разборов security-скиллов автор сравнил свой детальный промпт под Laravel с более широким запросом от другого разработчика, и широкий вариант нашел больше реальных проблем. Вывод: не пытайтесь сузить промпт до одной технологии, дайте AI сценарии, а не инструкцию «проверь безопасность».

Рабочий шаблон для Claude Code или Codex:

Проведи security-аудит проекта. Проверь конкретно:
1. Может ли пользователь через API изменить свой тарифный план или лимиты без прав на это
2. Может ли пользователь прочитать или изменить данные другого пользователя (IDOR)
3. Есть ли API-ключи, токены или пароли в коде фронтенда или в git-истории
4. Вызываются ли Stripe, AI-провайдеры, email-сервисы напрямую с клиента
5. Есть ли рейт-лимиты на бэкенде для всех тяжелых или платных операций
6. Есть ли в зависимостях пакеты с подозрительно короткой историей или без активности
Для каждой находки дай: файл, строку, критичность, минимальное исправление.

Дополните запросом на «bounded fix», попросите AI не просто найти проблему, а воспроизвести уязвимость и предложить минимальное исправление, не трогая остальную логику. Прогоните такой аудит два-три раза: результаты отличаются от запуска к запуску.

Как AI-инструменты для аудита кода отличаются между собой?

Claude Code показывает встроенное сканирование и лучшую защиту от промпт-инъекций среди сравниваемых ассистентов, но ни один инструмент не заменяет ревью человеком.

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

В каталоге AI-инструментов для вайбкодинга есть обзоры Claude Code и Cursor, они помогут выбрать связку под задачу, но финальная ответственность за проверку остается на разработчике, а не на модели.

Глоссарий терминов безопасности вайбкодинга

• RLS (Row Level Security) это механизм PostgreSQL и Supabase, ограничивающий доступ к строкам таблицы на уровне базы данных, а не приложения.
• IDOR (Insecure Direct Object Reference) это уязвимость, когда можно получить чужой объект, просто поменяв ID в запросе.
• Rate limit это ограничение числа запросов от пользователя или IP за период времени.
• Budget cap это жесткий лимит трат у облачного или AI-провайдера, после которого сервис отключается.
• SAST/DAST это статический и динамический анализ кода на уязвимости, отдельный от AI-ревью инструмент.
• Bounded fix это минимальное исправление уязвимости без изменения остальной логики кода.

Часто задаваемые вопросы про безопасность вайбкодинга

Правда ли, что вайбкодинг менее безопасен, чем обычная разработка?

Не обязательно. Разбор AI-инструментов для написания кода показывает: AI видит больше edge-кейсов, чем уставший разработчик под конец дня, но не заменяет ревью человеком. Опасность не в самом AI, а в публикации без проверки.

Сколько времени занимает проверка чеклиста из 20 пунктов?

От часа до вечера в зависимости от размера проекта. Большую часть пунктов можно закрыть одним промптом для Claude Code или Codex, дальше, ручная проверка критичных мест: авторизация, платежи, секреты.

Нужен ли отдельный SAST-инструмент, если уже использую Claude Code для аудита?

Да, для продакшена. Встроенное сканирование AI-ассистентов, это превью-функция, а не замена полноценного SAST/DAST. Для реального проекта с пользовательскими данными это дополнительный слой, а не альтернатива.

Что делать, если ключ уже утек в публичный репозиторий?

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

Как проверить RLS в Supabase без глубоких знаний SQL?

Опишите AI конкретные сценарии словами: «может ли пользователь A увидеть данные пользователя B», «может ли пользователь поменять себе лимит запросов». Такая формулировка ловит логические дыры лучше, чем просьба «проверь RLS».

Обязательно ли настраивать IP-based рейт-лимит, если уже есть лимит на пользователя?

Желательно. Пользовательский лимит не спасает от массового создания аккаунтов, IP-лимит закрывает этот сценарий отдельно.

Может ли AI сам одобрять свой код перед деплоем?

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

Итог

20 пунктов сверху закрывают основные дыры вайбкодинг-проекта: секреты, авторизацию, инпуты, зависимости и логи. Ни один пункт не требует днями кода, большинство закрываются промптом и получасом ручной проверки перед публикацией. Посмотрите каталог AI-инструментов для вайбкодинга, чтобы выбрать связку под свой стек. Если процессы безопасности и деплоя нужно выстроить под конкретную команду, посмотрите агента для DevOps-задач или запишитесь на консультацию к Максиму.

Обновлено: июль 2026.