Безпека вайб-кодингу: 12 ризиків у застосунках, створених ШІ, і як їх усунути

Безпека вайб-кодингу зводиться до короткого списку прогалин, які залишають ШІ-конструктори: секрети в браузері, відсутні перевірки доступу, незахищені бази даних і жодної змоги побачити чи відкотити шкоду. Більшість із них можна перевірити за день і виправити за кілька тижнів — ще до того, як прийдуть реальні користувачі та їхні дані.

Головне

• ШІ-інструменти пишуть код, який працює, а не код, для якого змодельовано загрози. Безпека — досі ваша відповідальність.
• Найнебезпечніші прогалини стосуються доступу: хто які дані може читати і які ключі лежать у браузері.
• Якщо ваш застосунок використовує Supabase, найважливіша перевірка — Row-Level Security на кожній таблиці.
• Для кожного ризику нижче є швидкий тест, який ви можете провести самі, перш ніж комусь платити.
• Спершу виправте доступ і секрети, потім додайте логування та резервні копії, які допоможуть відновитися після того, що ви пропустили.

Чому застосунки, створені вайб-кодингом, ризиковані

Такі застосунки ризиковані, бо ШІ оптимізує код під робоче демо, а демо ніколи не стикається з атакою. Код проходить «щасливий сценарій», а перевірок, які не дають сторонній людині читати дані інших користувачів, часто немає.

Це підтверджують цифри. У тесті Veracode 2025 року понад 100 мовних моделей виконали 80 завдань із програмування, і в 45% випадків згенерований код містив вразливість. Від міжсайтового скриптингу моделі не захистили код у 86% релевантних випадків, а від інʼєкцій у логи — у 88% (Veracode, July 2025).

Друга прогалина — людина, яка пише промпти. Засновник бачить, що сторінка входу працює, але не бачить, що API за нею приймає будь-який ID користувача. Тому в застосунках, створених ШІ, раз у раз трапляється той самий набір проблем. Якщо ви ще обираєте конструктор, у нашому порівнянні альтернатив Lovable розібрано, як кожен із них працює з кодом і хостингом.

12 ризиків безпеки вайб-кодингу і як їх усунути

Дванадцять ризиків нижче спираються на OWASP Top 10:2025 і на те, як ШІ-конструктори налаштовують застосунки. Для кожного є швидка перевірка та спосіб виправлення. Почніть згори: перші чотири відкривають доступ до даних, тож вони найважливіші.

1. Відкриті API-ключі

Що це. Ключі Stripe, OpenAI, поштового сервісу чи бази даних потрапляють у репозиторій — часто в ранньому коміті, який ШІ зробив ще до того, як ви попросили винести їх у змінні середовища. GitGuardian нарахував 23,8 мільйона секретів, що витекли в публічний GitHub у 2024 році, причому 70% секретів, які витекли у 2022-му, досі були дійсними (GitGuardian).

Як перевірити. Проскануйте сканером секретів, наприклад gitleaks або GitGuardian, усю історію Git, а не лише останні файли.

Як виправити. Замініть кожен ключ, який хоч раз потрапляв у коміт: видалення файлу не прибирає його з історії. Перенесіть ключі в сховище секретів вашої хостинг-платформи.

2. Відсутні перевірки авторизації

Що це. Застосунок перевіряє, що користувач увійшов, але не перевіряє, чи належить йому запитаний запис. Змініть ID в URL або виклику API — і побачите чуже замовлення. OWASP ставить цей ризик, Broken Access Control, на перше місце серед вебризиків.

Як перевірити. Увійдіть як користувач A, скопіюйте запит із вкладки Network у браузері та повторіть його з ID запису користувача B.

Як виправити. Перевіряйте право власності на сервері для кожного читання й запису — в одній спільній функції або політиці бази даних, а не на кожному екрані окремо.

3. Вимкнений Row-Level Security у Supabase

Що це. Lovable, Bolt і багато проєктів у Cursor використовують Supabase, де браузер звертається до бази даних напряму. Це безпечно лише з Row-Level Security (RLS). Власна документація Supabase радить «вмикати RLS на кожній таблиці у відкритій схемі» (Supabase RLS). У CVE-2025-48757 описано проєкти Lovable, чиї слабкі політики дозволяли неавторизованим користувачам читати таблиці; Lovable це заперечує (запис CVE).

Як перевірити. У дашборді Supabase відкрийте кожну таблицю й переконайтеся, що RLS увімкнено і політики налаштовано. Потім зверніться до API лише з публічним ключем і без сесії користувача.

Як виправити. Увімкніть RLS усюди та напишіть політики для кожної дії (select, insert, update, delete), привʼязані до auth.uid().

4. Секрети в клієнтському коді

Що це. Це не те саме, що витік із репозиторію: тут секрет потрапляє в браузер кожного відвідувача. Vite відкриває будь-яку змінну з префіксом VITE_, а Next.js вбудовує змінні NEXT_PUBLIC_ у JavaScript-бандл (Vite, Next.js). ШІ, якому потрібен ключ, «щоб усе запрацювало», часто додає цей префікс.

Як перевірити. Відкрийте розгорнутий сайт, перегляньте JavaScript-файли в інструментах розробника й пошукайте sk_, secret і service_role.

Як виправити. У браузері можуть бути лише публічні ключі. Supabase прямо попереджає, що секретний ключ «обходить усі політики Row Level Security» і ніколи не має потрапляти в браузер (Supabase API keys). Винесіть виклики, яким потрібні секрети, у серверну функцію.

5. Немає валідації вхідних даних

Що це. Форми та API приймають усе, що надходить: відʼємні ціни, імена на 10 МБ, HTML у полі коментаря. Фронтенд перевіряє дані, але будь-хто може його оминути.

Як перевірити. Надішліть запити напряму в API з неправильними типами, порожніми полями та дуже довгими рядками.

Як виправити. Валідуйте дані на сервері за допомогою бібліотеки схем, наприклад Zod, або валідатора вашого фреймворку й відхиляйте все, що не відповідає схемі.

6. Інʼєкції

Що це. Введені користувачем дані стають частиною запиту до бази, shell-команди чи HTML сторінки. Класичні форми — SQL-інʼєкції та міжсайтовий скриптинг (XSS), і саме на XSS моделі в дослідженні Veracode помилялися найчастіше.

Як перевірити. Пошукайте в коді запити, зібрані конкатенацією рядків, а також dangerouslySetInnerHTML чи v-html для контенту користувачів.

Як виправити. Використовуйте параметризовані запити або ORM та екрануйте чи очищуйте все, що виводиться як HTML.

7. Небезпечне завантаження файлів

Що це. Завантаження аватарів чи документів приймає файли будь-якого типу й розміру, зберігає назву файлу від користувача і кладе файли в публічний бакет.

Як перевірити. Спробуйте завантажити файл .html або .svg зі скриптом усередині, а потім відкрийте його публічний URL. Перевірте, чи можна дістатися до файлів іншого користувача, вгадавши шлях.

Як виправити. Дотримуйтеся OWASP File Upload Cheat Sheet: дозволяйте лише потрібні розширення, перевіряйте справжній тип файлу, перейменовуйте файли на сервері, обмежуйте розмір і зберігайте приватні файли в приватному бакеті з політиками доступу.

8. Немає обмеження частоти запитів

Що це. Вхід, скидання пароля та ШІ-функції приймають необмежену кількість запитів. Це відкриває шлях для підбору паролів, а кожен виклик платного API, як-от LLM чи SMS-провайдера, оплачуєте ви. OWASP називає відсутність лімітів на платні сторонні сервіси причиною збоїв і неочікуваних витрат (OWASP API4:2023).

Як перевірити. Надішліть скриптом 100 запитів на вхід або до ШІ за хвилину і подивіться, чи хоч один буде відхилено.

Як виправити. Додайте ліміти на користувача та на IP для входу, скидання пароля й кожного ендпоінту, який коштує грошей, а також встановіть ліміти витрат у кабінетах провайдерів.

9. Застарілі залежності

Що це. ШІ обрав версії пакетів зі своїх навчальних даних, частина з них старі, і ніхто їх не оновлює. Software Supply Chain Failures — новий пункт у списку OWASP 2025 року, одразу на третьому місці.

Як перевірити. Запустіть npm audit або pnpm audit та увімкніть Dependabot чи Renovate в репозиторії.

Як виправити. Спершу оновіть пакети з відомими вразливостями, приберіть невикористовувані й перевіряйте нові пакети, перш ніж їх додавати.

10. Немає логування та сповіщень

Що це. Коли щось іде не так, немає жодного запису про те, хто що зробив. OWASP називає це Security Logging and Alerting Failures: без логів злам може місяцями лишатися непоміченим.

Як перевірити. Запитайте себе: якби вчора витекли дані користувача, чи змогли б ви сказати, який обліковий запис їх читав і коли?

Як виправити. Логуйте входи, помилки доступу та зміни чутливих записів, але не логуйте паролі й токени. Додайте відстеження помилок і сповіщення про сплески невдалих запитів.

11. Персональні дані в промптах для ШІ

Що це. ШІ-функції застосунку надсилають мовній моделі записи клієнтів, листи чи документи — іноді разом із даними інших користувачів в одному контексті. OWASP ставить Sensitive Information Disclosure на друге місце серед ризиків LLM (OWASP LLM02:2025).

Як перевірити. Прочитайте промпти, які формує застосунок, і випишіть кожне поле, що в них потрапляє. Перевірте умови зберігання даних у вашого ШІ-провайдера.

Як виправити. Надсилайте лише ті поля, які потрібні для завдання, маскуйте ідентифікатори, де це можливо, і застосовуйте до отриманих даних ті самі правила доступу, що й до решти застосунку.

12. Немає резервних копій

Що це. База даних працює на безкоштовному чи стандартному тарифі без перевіреного відновлення. У липні 2025 року AI-агент на Replit, за повідомленнями, видалив робочу базу даних під час заморожування коду; потім агент заявив, що відкат неможливий, і це затягнуло відновлення (AI Incident Database).

Як перевірити. Зʼясуйте, коли востаннє створювалася резервна копія, і відновіть її в окрему базу даних.

Як виправити. Увімкніть щоденні резервні копії або відновлення на момент часу (point-in-time recovery), тримайте продакшн окремо від розробки й не давайте AI-агентам права запису в продакшн.

Чекліст безпеки перед запуском

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

Коли потрібен аудит коду

Замовляйте аудит коду, коли застосунок зберігає дані, про витік яких вам довелося б повідомляти, або коли ви не можете самі провести перевірки вище. Кілька сигналів:

• Платні клієнти, медичні чи фінансові дані або будь-що, що підпадає під закони про захист персональних даних
• Інвестор чи корпоративний клієнт попросив провести перевірку безпеки
• Два або більше рядків чекліста не проходять або їхній стан невідомий
• Ніхто в команді не може прочитати бекенд і політики бази даних

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

Як Join.To.IT може допомогти

Join.To.IT перевіряє й виправляє застосунки, створені в Lovable, Bolt, Cursor і Replit. Перевірка готовності до продакшну коштує $300–$800 і триває до тижня: ми тестуємо застосунок як клієнт і як зловмисник, перевіряємо кожен ризик із цього списку й ранжуємо знахідки за ризиком для запуску. Ви отримуєте результати та фіксовану оцінку ще до початку більших робіт. Потім ми закриваємо прогалини — від правил доступу й секретів до логування, резервних копій і CI/CD. Докладніше: як вивести ШІ-MVP (мінімальний життєздатний продукт) у продакшн.

Ті самі перевірки ми проводимо на власних системах. У жовтні 2026 року, після критичних патчів для GitLab, Node.js і PHP, ми виявили невстановлені патчі безпеки в нашому GitLab, вразливий Node.js в образі від постачальника нашого командного чату та версії PHP із завершеною підтримкою на одному сервері. Ми встановили патчі безпеки GitLab, роблячи резервну копію перед кожним кроком, перезібрали образ чату на пропатченому Node.js ще до того, як постачальник випустив свій, і оновили всі версії PHP. Чат був недоступний менше двох хвилин.

Часті запитання

Чи безпечний вайб-кодинг для продакшну?

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

Як провести аудит застосунку, створеного вайб-кодингом?

Почніть із доступу: повторіть запити від імені іншого користувача, зверніться до бази даних лише з публічним ключем і пошукайте секретні ключі в розгорнутому JavaScript. Потім проскануйте історію Git на витік ключів, запустіть аудит залежностей, протестуйте завантаження файлів і ліміти запитів та переконайтеся, що резервні копії відновлюються. Чекліст у цій статті описує кожен крок і те, як виглядає успішна перевірка.

Які проблеми безпеки найчастіше трапляються в коді, згенерованому ШІ?

Найчастіше це відсутні перевірки авторизації, таблиці бази даних без правил доступу, секретні ключі, відкриті в браузері, і відсутня валідація вхідних даних. Дослідження Veracode 2025 року виявило вразливості в 45% тестових випадків із кодом, згенерованим ШІ, а серед найчастіших збоїв — міжсайтовий скриптинг та інʼєкції в логи. Одразу за ними йдуть застарілі залежності та відсутність логів.

Чи можна виправити застосунок, створений у Bolt або Lovable?

Так. Більшість застосунків, створених у Bolt або Lovable, можна виправити без переписування: екрани й сценарії зазвичай лишаються, а правила доступу, робота із секретами та серверна логіка переробляються. Спершу експортуйте код у Git-репозиторій, потім проведіть перевірку готовності, щоб зрозуміти, що можна залишити. Перебудова потрібна лише тоді, коли сама модель даних хибна.