Безопасность вайб-кодинга: 16 проверок, которые закрывают ИИ-сервис перед запуском

Безопасность вайб-кодинга начинается с 16 конкретных проверок: вход, роли, доступ к данным, платежи, файлы, лимиты платных API и ключи. Если сервис собран ИИ-агентом за несколько дней, перед публикацией нужно проверить каждую "дверь" и получить доказательство в коде.

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

Какие риски чаще всего остаются после сборки ИИ-агентом?

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

Проверка начинается с простого вопроса: где сервис принимает решение, можно ли выполнить действие. Если решение принято только во фронтенде, кнопкой или видимостью элемента, защиты нет. Защита должна жить на сервере, в правилах базы или в платёжном обработчике.

Быстрая карта рисков

Почему общая просьба «проверь безопасность» не работает?

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

Плохая постановка звучит так: «Проверь проект на уязвимости». В ней нет списка "дверей", нет границ и нет формата доказательства. Агент может просмотреть несколько файлов, не найти очевидного дефекта и написать, что критичных проблем не видно.

Хорошая постановка звучит иначе: «Проверь все эндпоинты, которые отдают данные по id. В каждом покажи, где сервер убеждается, что объект принадлежит текущему пользователю». Такой запрос уже нельзя закрыть красивой фразой. Нужны файлы, строки и конкретные проверки.

Какие 16 "дверей" нужно пройти перед публикацией?

Перед публикацией ИИ-сервиса нужно пройти 16 "дверей": от входа и ролей до ключей, платёжных вебхуков и запасного доступа владельца. Этот список закрывает не все возможные классы атак, но даёт практическую приёмку для малого продукта, MVP, лендинга с личным кабинетом или внутреннего инструмента.

1. Вход без ограничения попыток. Форма принимает пароль сколько угодно раз. Нужны лимиты по IP и логину, временная блокировка и журнал ошибок.
2. Пароль из чужой утечки. Пользователь повторил старую связку «почта + пароль». Для админов нужна двухфакторная защита, для всех - нормальная политика паролей.
3. Ключи и токены в открытой части проекта. Токен бота, API-ключ или строка базы попали во фронтенд, публичный репозиторий или историю git.
4. Чужой заказ по соседнему номеру. Сервер проверил вход, но не проверил владельца записи.
5. Кнопка скрыта, а действие открыто. В интерфейсе кнопку видит только админ, но сервер выполняет запрос от любого пользователя.
6. Поиск или фильтр выполняет лишнее. Пользовательский ввод попадает в SQL или другой запрос как часть команды, а не как данные.
7. Платёжное уведомление можно подделать. Вебхук открывает доступ без проверки подписи, суммы, валюты и повторной отправки.
8. Зависимости взяты без проверки. Библиотека установлена ради скорости, но не проверены поддержка, свежесть и известные уязвимости.
9. Отзыв или комментарий запускает код. Текст пользователя выводится как HTML и может выполниться в браузере.
10. Сервер разрешает запросы с любого сайта. CORS оставлен открытым как на разработке, хотя сервис уже в интернете.
11. Загруженный файл оказался не тем, чем кажется. Проверяется только расширение, а не содержимое, размер, место хранения и возможность выполнения.
12. Одновременные запросы обходят счётчик. Промокод, бонус, лимит или списание не защищены от параллельных запросов.
13. База открыта шире, чем нужно. В Supabase, Firebase или другой базе не настроены правила доступа к строкам и коллекциям.
14. Нейросеть вызывают без лимитов. Форма обращается к платной модели без ограничений по пользователю, IP, сессии или тарифу.
15. Чужой код приносит чужие инструкции. Скилл, шаблон или пакет получает доступ к файлам и инструментам агента без проверки источника.
16. Ключи правят без запасного входа. Ошибка в доступах закрывает владельцу вход на сервер, а консоль или резервная сессия не подготовлены.

На какие стандарты опирается чек-лист?

Чек-лист сопоставлен с OWASP API Security Top 10 2023 и материалами OWASP по LLM-приложениям, поэтому 16 "дверей" связаны с признанными классами риска: доступом к объектам, авторизацией, лимитами ресурсов, зависимостями, выводом модели и утечками данных. Это не заменяет полноценный аудит, но помогает малому сервису пройти первую практическую приёмку перед публикацией.

Аналитика редакции

Для входа отдельно полезна OWASP Authentication Cheat Sheet: там разобраны ограничение попыток входа и многофакторная защита. В статье мы не пересказываем стандарт целиком, а переводим его в задачи, которые можно дать агенту и потом проверить руками.

Как поставить задачу агенту, чтобы не получить общий пустой ответ?

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

Используйте один шаблон для каждого риска:

1. Найди все места, где этот риск может появиться.
2. Покажи файл и строки.
3. Объясни, какая защита уже есть.
4. Если защиты нет, добавь её.
5. Покажи, как убедиться, что защита работает.

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

Что проверить в первый час?

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

Порядок такой:

1. Откройте чужой объект по соседнему id в тестовой среде: заказ, заявку, файл, профиль, статус.
2. Проверьте серверные роли: админское действие должно отказывать не-админу даже при ручной отправке запроса.
3. Поищите секреты в отслеживаемых файлах без вывода значений: важны имена файлов, а не сами ключи.
4. Проверьте лимит платных вызовов: модель, SMS, генерация изображений, карты, распознавание.
5. Откройте запасной вход перед правками ключей: консоль хостинга или резервная сессия должны быть готовы заранее.

Эта проверка не заменяет полноценную приёмку, но быстро показывает, насколько сервис вообще готов жить с реальными пользователями.

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

Проблема закрыта только тогда, когда проверка "умеет упасть" на намеренно сломанном сценарии и пройти после исправления. Отчёт агента сам по себе не является доказательством.

Если агент добавил ограничение попыток входа, проверьте шестую попытку. Если он добавил проверку владельца заказа, попробуйте открыть чужой id тестовым пользователем. Если он настроил CORS, проверьте запрос с чужого домена. Если он перенёс ключи в окружение, убедитесь, что они не попадают в клиентскую сборку.

Для задач безопасности полезен принцип «сломай нарочно». В тестовой ветке временно уберите проверку и убедитесь, что тест или ручной сценарий ловит проблему. Потом верните защиту и проверьте снова.

Чем этот чек-лист помогает KrutMaxAI™ и клиентским проектам?

Чек-лист превращает безопасность ИИ-сервиса в рабочую приёмку: агент получает не тревожную фразу, а список задач с ожидаемым результатом. Это особенно важно для проектов, которые быстро собираются под демо, MVP или первую продажу.

В KrutMaxAI™ мы используем такой формат для собственных демо и клиентских сборок: сначала работающий сервис, затем приёмка "по дверям", затем публикация. Это не делает маленький проект «корпоративной системой безопасности», но убирает типовые открытые места до того, как туда попадут реальные заявки, платежи и данные.

Читайте также: как создать ИИ-агента для ресёрча за семь шагов и как внедрить ИИ в малый бизнес без риска.

Что делать дальше?

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

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

Забрать чек-лист → https://t.me/Warmup12_bot?start=gate_checklist