Вайбкодинг і безпека: що нові дослідження 2026 кажуть бізнесу

Застосунок, який ШІ-агент зібрав за вечір, може працювати бездоганно і водночас віддавати чужі дані будь-кому, хто знає адресу API. Два дослідження, опубліковані на arXiv цього літа й осені, вперше показали масштаб: у 182 із 200 публічно розгорнутих «вайбкодних» застосунків знайшли щонайменше одну вразливість.

Це не привід відмовлятися від ШІ в розробці. Але це привід зрозуміти, де саме агенти помиляються і що перевірити, перш ніж пускати на такий сайт клієнтів і їхні гроші.

91 %

перевірених застосунків мають вразливість

182 із 200

65,8 %

знайдених вразливостей — критичні або високі

із 1186 підтверджених

55,5 %

проблем через захист, про який ніхто не попросив

найчастіша причина

Джерело: Deng, Fan, Meng, «Understanding the (In)Security of Vibe-Coded Applications», arXiv, 2026

Чому про це варто говорити саме зараз

Вайбкодинг — це спосіб розробки, коли людина описує задачу звичайною мовою, а код пише ШІ-агент: 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.