Безпека вайбкодингу: що перевірити, перш ніж запускати сайт, створений з AI

Чому зараз усі займаються вайбкодингом

Вайбкодинг — це коли ви описуєте звичайною мовою, що хочете отримати, а код пише AI-інструмент. Так засновники збирають MVP, дизайнери запускають власні лендинги, а маркетологи створюють внутрішні інструменти, не чекаючи на розробників.

Розробники користуються AI не менше. В опитуванні Stack Overflow Developer Survey 2025 (відкриється в новій вкладці) 84% респондентів сказали, що використовують або планують використовувати AI-інструменти — рік тому таких було 76%. Те саме опитування показує й зворотний бік: 46% розробників не довіряють точності відповідей AI, і лише 3% довіряють їм повністю.

У цьому розриві вся суть. Люди, які пишуть код професійно, щодня користуються AI і все одно перевіряють результат. Багато хто, хто вперше створює щось з AI, просто не знає, що саме перевіряти.

Чому код від AI часто небезпечний

AI-інструменти навчені створювати код, який працює, а не код, який безпечний. У звіті Veracode 2025 GenAI Code Security Report (відкриється в новій вкладці) код від понад 100 мовних моделей містив уразливості зі списку OWASP Top 10 у 45% тестових завдань. Новіші моделі писали код, який краще працює, але не безпечніший.

Причин три.

• У запиті рідко згадують безпеку. «Зроби форму бронювання» — і ви отримуєте форму бронювання. Ніхто не запитав, хто може читати бронювання.
• Модель не бачить усієї системи. Вона пише код частинами й не знає, де зберігаються ваші дані, хто ваші користувачі й що могло б зацікавити зловмисника.
• Вона навчалася на публічному коді. А публічний код повний скорочень і навчальних прикладів, які ніколи не призначалися для робочих продуктів, — і модель упевнено їх повторює.

Результат виглядає завершеним. Інтерфейс охайний, демо працює, а проблеми непомітні, доки хтось не почне їх шукати.

7 найпоширеніших проблем безпеки у сайтах і застосунках, створених вайбкодингом

Саме ці проблеми я найчастіше бачу, коли переглядаю проєкти, створені з AI. Жодна з них не потребує досвідченого хакера. Більшість може знайти будь-хто, хто відкриє інструменти розробника в браузері.

1. Секретні ключі в коді браузера

AI-інструменти часто вставляють API-ключі OpenAI, Stripe чи поштових сервісів прямо у фронтенд-код, щоб функція запрацювала. Усе, що є в браузері, — публічне. Витік ключа означає, що хтось інший витрачає ваші гроші або надсилає листи від вашого імені.

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

2. База даних, яку може прочитати будь-хто

Багато AI-конструкторів підключають застосунок напряму до хмарної бази даних. Це нормально, лише якщо в базі налаштовані правила, хто може читати й змінювати кожен запис. У 2025 році дослідник Метт Палмер перевірив 1 645 публічних застосунків, створених у Lovable, і знайшов 170 із таблицями (відкриється в новій вкладці), відкритими для будь-кого: в них були імена, email, адреси та API-ключі. Уразливість зареєстрували як CVE-2025-48757.

Що перевірити: у кожній таблиці увімкнені правила доступу, а відвідувач без входу в акаунт не може прочитати нічиїх даних.

3. Захист, який існує лише в інтерфейсі

Типова ситуація: кнопку «Видалити» сховано від звичайних користувачів, і застосунок виглядає захищеним. Але сервер усе одно приймає запит на видалення від будь-кого, хто його надішле. Сховати кнопку — це дизайн, а не безпека.

Що перевірити: кожна дія, яка змінює чи відкриває дані, перевіряється на сервері — для кожного запиту.

4. Довіра до всього, що надсилають користувачі

Форми, завантаження файлів і параметри в URL — це дані від незнайомців. Код від AI часто приймає їх як є, а це відчиняє двері спаму, пошкодженим даним та ін'єкційним атакам.

Що перевірити: вхідні дані перевіряються на сервері, завантаження обмежені за типом і розміром, а форми захищені від ботів.

5. Пакети, яких не існує

AI-інструменти іноді радять програмні бібліотеки, які ніколи не публікувалися. Дослідження, представлене на USENIX Security 2025 (відкриється в новій вкладці), перевірило 16 моделей: 19,7% запропонованих ними пакетів не існувало. Зловмисники реєструють ці вигадані назви зі шкідливим кодом усередині — цю техніку назвали slopsquatting.

Що перевірити: кожна залежність реальна, підтримується розробниками й справді потрібна. Менше пакетів — менше дверей для атаки.

6. AI-агенти із надто широкими правами

Агенти, які можуть виконувати команди, — потужний інструмент, і помиляються вони впевнено. У липні 2025 року агент Replit видалив робочу базу даних (відкриється в новій вкладці) під час «заморозки коду» в публічному експерименті засновника SaaStr Джейсона Лемкіна. На той момент одна й та сама база використовувалася і для розробки, і для робочого продукту.

Що перевірити: середовища розробки, тестування й продакшну розділені, і жоден AI-інструмент не має права запису в живі дані.

7. Немає страховки

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

Що перевірити: автоматичні резервні копії, які ви хоча б раз відновлювали; моніторинг, що сповіщає людину; залежності, які вчасно оновлюються.

Чи безпечний вайбкодинг для сайту бізнесу?

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

Просте правило: щойно реальні люди довіряють вашому застосунку свої дані чи гроші, «воно працює» — вже недостатньо.

Чек-лист із 10 пунктів перед запуском

Використовуйте його як першу перевірку, перш ніж сайт чи застосунок, створений з AI, стане публічним. Якщо на якийсь пункт ви не можете впевнено відповісти «так» — саме там найбільше допоможе погляд збоку.

1. У коді, що виконується в браузері, немає секретних ключів.
2. У кожній таблиці бази даних є правила доступу, а відвідувач без входу не бачить приватних даних.
3. Кожна дія, що змінює дані, перевіряється на сервері, а не лише ховається в інтерфейсі.
4. Форми й завантаження перевіряються на сервері та захищені від ботів.
5. Кожен пакет у проєкті існує, підтримується й справді використовується.
6. Розробка, тестування й продакшн мають окремі бази даних і ключі.
7. Жоден AI-агент чи інструмент не має права запису в продакшн.
8. Паролі та вхід працюють через перевірений сервіс або бібліотеку, а не власний код.
9. Резервні копії створюються автоматично, і ви перевірили відновлення хоча б однієї.
10. Хтось отримує сповіщення, коли сайт ламається або поводиться незвично.

Цей список ловить найпоширеніші проблеми. Це не повний аудит безпеки — а застосунку, що працює з оплатами чи чутливими даними, він потрібен.

Як ми використовуємо AI у ROOKS

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

Чого AI не робить у ROOKS:

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

У результаті ви отримуєте швидкість AI і відповідальність команди з чотирьох інженерів, де ті, з ким ви спілкуєтеся, самі пишуть і перевіряють код.