Безопасны ли приложения на вайб-кодинге? 8 уязвимостей

Безопасны ли приложения, созданные вайб-кодингом?

Не по умолчанию: все крупные исследования, приведённые здесь, нашли серьёзные уязвимости у значительной части проверенных приложений ^[3][4][5]. Приложения обычно работают. Проблема в том, что они позволяют делать посторонним.

Аудит 2026 года собрал 9.041 приложение с открытым кодом, созданное с помощью Claude Code и Lovable, и изучил 200 из них, опубликованных в открытом доступе. Он нашёл 1.186 уязвимостей, и в 182 из 200 приложений (91,0%) была хотя бы одна ^[4]. Из этих уязвимостей 65,77% получили критический или высокий уровень, в том числе 18,47% — критический ^[4].

Авторы также проверили, решают ли проблему более удачные промпты и настройки агентов. Они уменьшили её, но не устранили, а одна и та же задача, запущенная трижды, могла один раз дать безопасный результат, а в следующий — уязвимый ^[4]. Иначе говоря, чистый результат одной сборки мало говорит о следующей.

Основы метода описаны в руководстве Pouyam Vibe Coding Explained: What It Is, How It Works and the Real Risks («Что такое вайб-кодинг и каковы реальные риски»). Для первого проекта план старта даёт Vibe Coding for Beginners: How to Start Safely in 2026 («Вайб-кодинг для начинающих»). Эта страница идёт на уровень глубже: конкретные уязвимости и способы проверить каждую.

Что находят исследования безопасности в приложениях на вайб-кодинге?

Четыре независимых источника указывают на одно слабое место: данные, которые может прочитать или изменить не тот человек ^[1][3][4][5].

• Аудит 200 опубликованных приложений (2026): нарушение контроля доступа стало крупнейшей категорией — 339 из 1.186 уязвимостей (28,58%) — и затронуло 64,00% приложений. Инъекции затронули 54,00%, ошибки аутентификации — 51,50% ^[4].
• Исследование ACM CCS 2026: в 8.641 репозитории Lovable с полной историей 11,2% правил чтения были открыты для посетителей без входа, а в 61,2% репозиториев было хотя бы одно такое правило. Повторная проверка подтвердила утечку в 353 из 400 выбранных репозиториев ^[5].
• Escape (октябрь 2025): пассивное сканирование более 5.600 публичных приложений на платформах вроде Lovable, Base44 и Create.xyz нашло более 2.000 уязвимостей, более 400 раскрытых секретов и 175 случаев утечки персональных данных, включая медицинские записи, IBAN (идентификаторы банковских счетов), телефоны и адреса электронной почты ^[3].
• CVE-2025-48757 (2025): сканирование, завершённое 21 марта 2025 года, нашло 303 точки доступа к базам данных в 170 из 1.645 проектов Lovable, примерно 10,3%, с недостаточными правилами на уровне строк ^[1].

Escape подчёркивает, что сканирование не выполняло никаких разрушительных действий, поэтому её цифры — нижняя граница; более глубокая проверка нашла бы больше ^[3]. Та же оговорка касается всех цифр здесь: исследования считают то, что было видно снаружи.

Почему инструменты ИИ создают небезопасные приложения?

Потому что инструменты стремятся к работающему приложению, а правила безопасности зависят от бизнес-деталей, которые в промпте почти никогда не прописаны ^[4][11].

Работающий код легко проверить: страница загружается, кнопка нажимается. А кто может видеть каждую запись — это бизнес-решение, и если его никто не записал, инструменту приходится угадывать. Аудит 2026 года связывает уязвимости с восемью повторяющимися типами сбоев, сгруппированными в три ограничения агентов ИИ: память, цели и знания ^[4].

Широкие тесты моделей ИИ показывают тот же разрыв. Отчёт Veracode GenAI Code Security Report 2026 показал, что в её тестах примерно в 44% задач по генерации кода появлялась уязвимость безопасности ^[11]. Бенчмарк, на который ссылается AWS, показал, что лучшая из 12 конфигураций агентов правильно решила 57% задач, но лишь 11,8% — одновременно правильно и безопасно ^[10].

Кроме того, многие приложения на вайб-кодинге переносят безопасность в базу данных. Браузер обращается напрямую к размещённой базе, поэтому её правила — единственное, что стоит между посетителем и каждой строкой ^[1][6]. Если правил нет или они слишком широкие, любой, кто знает адрес, может запросить всё.

Какие 8 уязвимостей проверить в первую очередь?

Начните с уязвимостей, которые исследования находят чаще всего, в порядке возможного ущерба ^[1][3][4][5].

1. Открытые правила базы данных: таблицы без защиты на уровне строк или с правилами, позволяющими любому посетителю читать все строки. Именно это стало причиной CVE-2025-48757 и находок ACM ^[1][5].
2. Нарушение контроля доступа: вошедший пользователь открывает чужую запись, меняя идентификатор в адресе или запросе. Это крупнейшая категория аудита 2026 года ^[4].
3. Секретные ключи в браузере: ключ secret или service_role от Supabase, платёжный ключ или ключ провайдера ИИ в клиентском коде. Escape нашла более 400 раскрытых секретов ^[3][6].
4. Отсутствующая или слабая проверка входа: закрытые страницы или маршруты API, отвечающие без сессии. Ошибки аутентификации затронули 51,50% проверенных приложений ^[4].
5. Инъекции: пользовательский ввод без проверки попадает в запросы к базе или в HTML; обнаружено в 54,00% проверенных приложений ^[4].
6. Таблицы, открытые для записи: правила, позволяющие посетителям не только читать, но и добавлять или менять данные. В случае с CVE запрос без токена входа добавил запись с отметкой «оплачено» и пропустил шаг оплаты ^[1].
7. Избыточные ответы: API, которые возвращают целые записи пользователей, адреса почты или токены, когда странице нужно только имя. Escape насчитала 175 случаев раскрытия персональных данных ^[3].
8. Рискованный доступ агентов: агент для программирования с рабочими учётными данными может нанести реальный ущерб; в июле 2025 года агент удалил рабочую базу данных во время заморозки кода ^[10].

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

Как проверить своё приложение на эти уязвимости?

Пользуйтесь приложением так, как это сделал бы атакующий: как посторонний, как второй пользователь и читая то, что получает браузер ^[1][4][5]. Ни один шаг не требует специальных инструментов.

1. Создайте две тестовые учётные записи. Создайте запись под учётной записью A, скопируйте её адрес или идентификатор, войдите как B и попробуйте открыть, изменить и удалить её. Если получилось, контроль доступа нарушен ^[4].
2. Повторите без входа. Откройте те же адреса в приватном окне без сессии. В случае с CVE удаления заголовка авторизации хватило, чтобы обойти все проверки ^[1].
3. Следите за вкладкой «Сеть». В инструментах разработчика браузера просмотрите каждый запрос страницы и ответ на него. Ответы должны содержать только то, что нужно этому экрану, и никогда — чужие адреса почты или токены ^[3].
4. Ищите ключи в коде страницы. Ищите строки, начинающиеся с sb_secret_, метку service_role или ключи провайдеров, например платёжные или ключи ИИ. Ключ publishable — это нормально; ключ secret — это авария ^[6].
5. Проверьте правила каждой таблицы. В панели базы данных убедитесь, что защита на уровне строк включена для каждой таблицы, и прочитайте каждое правило простыми словами: кто может читать, кто может писать ^[7].
6. Попробуйте странный ввод. Вставьте в каждую форму очень длинный текст, кавычки и HTML-теги и посмотрите, не ломается ли приложение и не показывает ли их как код ^[4].

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

Как исправить открытые правила Supabase и утёкшие ключи?

Включите защиту на уровне строк для каждой таблицы, пишите узкие правила, держите секретные ключи на сервере и заменяйте любой утёкший ключ ^[6][7][8].

• Включите защиту на уровне строк везде. Руководство Supabase советует включать её на каждой таблице в доступной извне схеме ^[7]. После включения публичный ключ ни к чему не получает доступа, пока вы не добавите правила ^[7].
• Отзовите права по умолчанию. В проектах, где их всё ещё выдают по умолчанию, новая публичная таблица создаётся с уже выданными всеми привилегиями для ролей без входа (anon) и с входом (authenticated), и добавление правил эти права не отзывает ^[7]. Отзовите их и верните каждой роли только необходимое ^[7].
• Пишите правила для каждого пользователя. Правило для закрытой таблицы должно сверяться с идентификатором вошедшего пользователя, а не просто пускать любого вошедшего. Избегайте всегда истинных правил для чувствительных таблиц ^[2].
• Держите секретные ключи на сервере. Ключ publishable в Supabase безопасен в браузере лишь потому, что его ограничивают правила на уровне строк; ключи secret и service_role обходят все правила и должны оставаться в серверном коде или защищённых переменных окружения ^[6].
• Заменяйте утёкшие ключи. Если секретный ключ хоть раз попал в браузер или публичный репозиторий кода, замените его и отключите скомпрометированный, как советует руководство Supabase по ключам ^[6].

По состоянию на 15 ноября 2026 года документация Supabase сообщает, что старые ключи anon и service_role выводятся из употребления до конца 2026 года в пользу ключей publishable и secret ^[8]. Новые ключи secret возвращают ошибку (HTTP 401) при использовании в браузере, хотя утёкший ключ всё ещё можно использовать из других инструментов ^[6][8]. Переход сейчас — хороший повод проверить каждый ключ, который использует приложение.

Встроенные сканеры безопасности находят всё?

Нет: сканеры платформ помогают, но ряд исследований показывает, что они пропускают самые важные правила ^[1][2][5].

В 2025 году исследователи, обнаружившие CVE-2025-48757, установили, что сканер Lovable проверял лишь наличие правила на уровне строк, а не его правильность ^[1]. В их бюллетене добавлено, что проверка Lovable при публикации отмечает таблицы без правил, но не показывает, достаточно ли строги правила ^[2]. Открытое правило такую проверку проходит.

Исследование ACM подтверждает это цифрами: даже скромная доля открытых правил — 6,3% по шести инструментам — оставила 56,9% репозиториев хотя бы с одной открытой таблицей, потому что одного открытого правила достаточно ^[5]. Авторы выпустили бесплатную программу проверки, которая отмечает такие правила до коммита ^[5].

Используйте сканеры как первый фильтр, а проверки с двумя учётными записями и без входа проводите сами. Таблица ниже сводит цифры вместе.

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

Будьте осторожны со всем, что запрашивает персональные, медицинские или платёжные данные, ведь пользователи не видят, как приложение их защищает ^[3][4]. Среди раскрытых данных Escape нашла медицинские записи и IBAN (идентификаторы банковских счетов) ^[3].

Несколько простых привычек снижают риск. Используйте отдельный пароль для каждого нового приложения, чтобы утечка в одном не открыла другие; как это сделать, объясняет руководство Pouyam Password Managers Explained: How They Work and Whether They Are Safe («Менеджеры паролей: как они работают»). Сообщайте только те данные, которые нужны приложению, и выбирайте страницы оплаты известных платёжных сервисов, а не формы внутри приложения.

Главная ответственность лежит на создателях. Если вы публикуете приложение, которое хранит чужие данные, проводите описанные проверки перед запуском и после каждого крупного изменения, ведь одна новая функция может снова открыть закрытую уязвимость ^[4][5].