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

Почему рабочая демонстрация ещё не значит безопасное приложение

Безопасность вайб-кодинга начинается с простого наблюдения. Вы описываете приложение в Cursor, Lovable, Bolt или v0, инструмент пишет код, и на экране всё работает. В этой цепочке никто не спрашивает, сможет ли посторонний открыть тот же адрес и прочитать чужие записи. Демонстрация проходит потому, что тестирует её один человек, он же владелец каждой строки в базе.

Риск растёт в день, когда приходят настоящие пользователи. С ними появляются имена, заказы и платежи. Список рисков OWASP Top 10:2021 показывает, что это обычная инженерная работа, а не экзотика. Дальше разберём слабые места, с которыми такое приложение сталкивается первыми, и то, что стоит проверить до запуска.

Нарушенный контроль доступа — слабое место номер один по версии OWASP

В OWASP Top 10:2021 нарушенный контроль доступа стоит на первом месте, поднявшись с пятого. OWASP определяет его одной строкой: контроль доступа обеспечивает политику, при которой пользователи не могут действовать за пределами своих прав. OWASP также отмечает, что на ту или иную форму этой проблемы проверили 94% приложений из его выборки, так что это обычный случай.

В приложении, собранном по подсказкам, такие дыры бывают в узнаваемых местах. Страница убрана из меню, но открывается, если набрать её адрес: OWASP называет это принудительным просмотром. В запросе передан номер заказа или аккаунта, и стоит его изменить, как открывается запись другого клиента. Метод сохранения или удаления проверяет, что человек вошёл, но не проверяет, что запись принадлежит ему. Отсутствие проверок у запросов POST, PUT и DELETE OWASP относит к типичным примерам.

Меры у OWASP простые. Запрещать всё по умолчанию, кроме публичных ресурсов. Проверять права в надёжном серверном коде, потому что браузер сам за собой не уследит. Привязывать доступ к владельцу записи и записывать отказы в журнал, чтобы повторные попытки кто-то заметил. Скрытая кнопка — не правило: если единственная защита в том, что ссылка на админку не показана, контроля доступа у приложения нет.

Ключи и секреты, которые оказываются на виду

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

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

Выход — отозвать ключ у провайдера и выпустить новый; GitHub называет это самым важным шагом. Затем посмотрите журналы провайдера: нет ли обращений, которых вы не узнаёте, — и храните новый ключ в настройках хостинга. Vercel добавляет практическую деталь: изменённая переменная действует только для новых развёртываний, поэтому после замены ключа нужен новый деплой.

Открытые правила базы данных и ловушка Row Level Security

Когда браузер подключён к облачной базе напрямую, единственным сторожем остаются правила самой базы. Документация Supabase о Row Level Security формулирует риск прямо: таблица в открытой схеме без RLS доступна на чтение и запись любой роли, у которой есть на неё права. Включить RLS — ещё не всё. На той же странице сказано, что нужны ещё подходящие права и политики и что после включения RLS API не отдаёт данных под публичным ключом, пока не создана политика. Политика «всегда истина» для анонимной роли открывает каждую строку любому посетителю, и руководство оставляет её для публичных данных.

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

Ошибки настройки: пароли по умолчанию, тексты ошибок и забытые остатки

Следующее семейство OWASP называет ошибками конфигурации безопасности и приводит три бытовых примера. Учётные записи по умолчанию и их пароли остались включёнными и не изменены. Обработка ошибок показывает пользователям трассировки стека и слишком подробные сообщения. Включены лишние возможности: страницы, учётные записи, привилегии. В сгенерированном проекте может найтись всё сразу: демонстрационный администратор, отладочный маршрут из первой сессии, сырая ошибка на экране.

Рекомендации OWASP читаются как список уборки. Начинать с минимальной платформы без лишних функций, компонентов, документации и примеров. Собирать каждую среду одинаково, но с отдельными учётными данными, чтобы у тестовой и боевой базы не было общего пароля. Проверять настройки автоматически, а не по памяти.

Однодневная проверка безопасности вайб-кодинга до первого клиента

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

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

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

Чинить или переписывать: как решить по письменному списку

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

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

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

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

Студия VITON13 предлагает пакет «Спасение приложения, сделанного с ИИ». В него входят проверка кода и настроек на безопасность, исправление того, что ломается, настройка развёртывания и чистка кода, чтобы следующий разработчик мог его прочитать. До оплаты студия присылает бесплатный черновик — список главных найденных проблем. Цена фиксированная, от $113, срок — от 5 до 10 рабочих дней.