Вайбкодинг и безопасность: что исследования 2026 говорят бизнесу
Приложение, которое ИИ-агент собрал за вечер, может отлично работать и при этом отдавать чужие данные любому, кто знает адрес API. Два исследования, вышедшие на arXiv этим летом и осенью, впервые показали масштаб: в 182 из 200 публично доступных «вайбкодных» приложений нашлась хотя бы одна уязвимость.
Отказываться от ИИ в разработке из-за этого не нужно. Но стоит понять, где именно агенты ошибаются и что проверить, прежде чем пускать на такой сайт клиентов, их данные и деньги.
Почему тема актуальна именно сейчас
Вайбкодинг — это разработка, при которой человек ставит задачу обычным языком, а код пишет ИИ-агент: Claude Code, Lovable, Copilot и похожие инструменты. Рынок растёт очень быстро. Как сообщает издание Tech.eu, в августе 2026 года Lovable привлёк $400 млн при оценке $13,3 млрд, а приложения, сделанные на платформе, набирают больше 900 млн посещений в месяц.
Значит, речь уже не о хобби разработчиков, а о кабинетах, сервисах и сайтах, с которыми работают реальные клиенты. И как раз сейчас появились первые серьёзные данные о том, насколько это безопасно.
Исследование 1: аудит 200 настоящих приложений
Цзюньцюань Дэн, Чжию Фань и Жуйцзе Мэн собрали на GitHub 9041 открытое приложение, где минимум 90 % кода и коммитов принадлежит ИИ-агенту (Claude Code или Lovable). У 984 из них нашлась публичная версия в интернете, и для глубокого аудита случайно выбрали 200. Каждую находку два автора подтверждали вручную.
Итог — 1186 подтверждённых уязвимостей, в среднем 6,5 на одно уязвимое приложение. Критических 18,5 %, высоких 47,3 %. Чуть больше половины проблем оказалось в серверной части, а не в интерфейсе.
Если разложить их по категориям OWASP (это международный список главных рисков веб-приложений), картина такая:
- Нарушенный контроль доступа 64 %
- Инъекции 54 %
- Ошибки аутентификации 51,5 %
- Криптографические ошибки 36,5 %
- Ошибки конфигурации 36,5 %
- Уязвимые зависимости 28 %
Источник: Deng, Fan, Meng, arXiv:2606.23130 (версия от 14.09.2026)
Если проще: чаще всего один пользователь может посмотреть или изменить данные другого, потому что сервер не проверяет, кому они принадлежат. Следом идут небезопасная обработка ввода и слабый вход в аккаунт. В действующем OWASP Top 10:2025 нарушенный контроль доступа тоже стоит на первом месте, так что исследование совпадает с общей картиной.
Откуда берутся ошибки
Самое полезное в работе — разбор причин. Авторы выделили восемь повторяющихся сценариев, основные из них:
| Причина | Доля уязвимостей | Как выглядит |
|---|---|---|
| Защита, о которой не попросили | 55,5 % | В запросе не было «проверяй права на сервере», и агент не стал |
| Код «для демонстрации» | 14,7 % | Фиксированный ключ или «шифрование» через base64 прямо в архитектуре |
| Изменение внесли не везде | 9,3 % | Проверку добавили в новые методы API, а старые остались без неё |
| Побочный эффект исправления | 8,4 % | Чтобы убрать ошибку на экране, агент ослабляет защиту |
| Безопасность оставлена человеку | 6,1 % | Агент пишет «не забудьте убрать ключи из репозитория» и на этом всё |
| Забытые обещания | 4,2 % | Пометка «добавить проверку пароля позже» доживает до релиза |
Наш вывод: дело не в том, что ИИ «плохо пишет код». Он делает ровно то, что попросили, и останавливается. А владелец бизнеса просит функцию («сделай личный кабинет»), а не правила безопасности, о которых он может и не знать.
Исследование 2: помогает, если попросить
Дарко Андрочец из Загребского университета проверил как раз это. В Claude Code он дважды сгенерировал шесть веб-приложений (блог, API задач, загрузку файлов, магазин, форму с предпросмотром ссылок, админку): один раз по обычному ТЗ, второй — по тому же ТЗ с добавленным разделом требований безопасности на основе OWASP.
Результат: 51 подтверждённая проблема в обычных версиях против 24 в версиях с требованиями, и улучшение есть в каждом из шести приложений. Критических и высоких проблем в «защищённых» версиях не осталось совсем. Автор прямо пишет об ограничениях: выборка маленькая, каждый вариант сгенерирован один раз, поэтому это наблюдение, а не доказанный эффект.
Ещё два вывода этой работы пригодятся на практике:
- Самую опасную проблему нашли только вручную. Токен входа подписывался ключом, вписанным прямо в код, поэтому любой мог войти под чужим аккаунтом. Ни один автоматический сканер этого не показал.
- Разные методы находят разное. Из 75 подтверждённых находок только 12 обнаружили больше чем одним способом. Если полагаться на один сканер, можно успокоиться раньше времени.
Как формулировка запроса меняет результат
Первая работа проверила и это — на 1680 прогонах. Агенту давали задачи, на которых раньше появлялись уязвимости, и смотрели, как часто проблема возвращается:
- Обычный запрос 25,7 %
- Запрос «сделай готовым к продакшену» 11 %
- Агент с навыком безопасной разработки 11,9 %
- Подробное техническое ТЗ 45,7 %
Источник: Deng, Fan, Meng, arXiv:2606.23130
Неожиданный результат: очень подробное техническое ТЗ ухудшило ситуацию. По версии авторов, агент начинает выполнять спецификацию буквально и не добавляет защиту, которой в ней нет. Кроме того, в 20,7 % прогонов, где уязвимость всё же появилась, агент сам замечал риск, но всё равно сдавал небезопасный код.
Чек-лист перед запуском сайта, сделанного с ИИ
Это наши рекомендации, а не требования какой-либо платформы. Они касаются любого проекта, где есть вход, личные данные, оплата или админка.
- Пропишите требования безопасности в первом же запросе. Проверка прав на сервере для каждого запроса, пароли только в виде хеша, секреты только из переменных окружения, защита форм, ограничения на загрузку файлов. По данным второго исследования, это уже заметно снижает число серьёзных проблем.
- Проверьте доступ «из-под другого пользователя». Заведите два тестовых аккаунта и попробуйте из одного открыть, изменить или удалить данные второго, подставив чужой ID в адрес или запрос.
- Поищите ключи в коде. Пройдитесь по репозиторию и собранному фронтенду в поисках строк вроде
secret,key,token. Всё, что попало в браузер, видно любому посетителю. - Если база на Supabase, проверьте RLS. Документация Supabase требует включать Row Level Security для каждой таблицы в открытой схеме, иначе данные можно читать и менять через публичный ключ. Секретный ключ, который обходит RLS, в браузер попадать не должен.
- Отключите режим отладки и подробные тексты ошибок на рабочем сайте.
- Сочетайте автоматику и ручную проверку. Сканер зависимостей и статический анализ — минимум, но логику доступа должен проверить человек.
- Проверяйте после каждого крупного изменения, а не только перед первым запуском: вспомните пункт «изменение внесли не везде» из таблицы.
Когда вайбкодинга хватает, а когда нет
По нашему мнению, граница проходит не по технологии, а по цене ошибки. Прототип, внутренний инструмент без персональных данных, лендинг без бэкенда — здесь вайбкодинг даёт скорость при небольшом риске. Личный кабинет клиента, оплата, CRM с базой контактов, админ-панель — здесь нужен человек, который понимает, что именно надо защитить, и проверяет это.
Если продукт уже вырос из прототипа и им пользуются клиенты, разумный следующий шаг — разработка веб-приложений с архитектурой, где права доступа, секреты и проверки заложены с первого дня, а ИИ остаётся инструментом ускорения.
Что делать дальше
- Если у вас уже есть сайт или сервис, собранный ИИ-агентом, пройдите чек-лист выше, начиная с проверки доступа между двумя аккаунтами.
- Новый проект начинайте с требований безопасности в запросе, а не с «сделай красиво».
- Всё, где есть деньги и персональные данные, отправляйте на ручной аудит до запуска.
Хотите, чтобы на ваше приложение посмотрел кто-то со стороны? Расскажите о проекте, и мы подскажем, что проверить в первую очередь.
Автор: Сергей Филатьев — основатель авторской студии Veb-Dev.
Теги
- вайбкодинг
- безопасность сайта
- ИИ-агенты
- Claude Code
- Lovable
- OWASP Top 10
- веб-приложение