Чи безпечний вайб кодинг? Реальні ризики та що перевірити перед публікацією

Вайб кодинг безпечний для особистих інструментів і прототипів, а для справжніх застосунків із реальними користувачами він може бути безпечним, але лише якщо ви додасте перевірки, які підхід «просто опишіть і подивіться, чи працює» пропускає. Небезпечні проблеми не видно з екрана: користувачі, які можуть відкрити дані одне одного, секретні ключі в браузері та публічні форми без жодних обмежень. Цей посібник пояснює ризики, які справді викликають проблеми, як поводитися з секретами, скільки перевірки потрібно і 30-хвилинну перевірку, яку варто провести перед публікацією.

Повний технічний список див. у нашому чек-листі безпеки для застосунків, створених ШІ. Ця сторінка — коротша й практична версія для тих, хто не читає код.

Чому вайб кодинг має власні ризики

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

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

Наскільки ризикований ваш застосунок? Коротка шкала

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

Ризики, які справді спричиняють проблеми

1. Користувачі бачать дані одне одного

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

Як перевірити: створіть два облікові записи. Увійдіть як користувач A, відкрийте один із записів A і запам’ятайте адресу. Увійдіть як користувач B в приватному вікні та вставте цю адресу. Ви маєте побачити «не знайдено», а не дані A.

Промпт:

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

2. Секрети в неправильному місці

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

Як перевірити: запитайте ШІ.

Перелічи кожен API-ключ, токен і пароль, який використовує цей застосунок. Для кожного скажи, де він зберігається і чи коли-небудь надсилається в браузер. Перенеси все, що є в коді або на фронтенді, у серверні секрети.

3. Публічні форми й ендпоінти без обмежень

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

Промпт:

Додай обмеження частоти запитів для реєстрації, входу, форми зворотного зв’язку та кожного ендпоінта, який викликає сервіс ШІ. Додай приховане поле-пастку (honeypot) до публічних форм. Скажи, які ліміти ти обрав.

4. Довіра до браузера

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

Промпт:

Знайди всі місця, де браузер вирішує те, що має вирішувати сервер: ціни, суми, права доступу, ролі, бали. Перенеси ці перевірки на сервер.

5. Немає шляху назад

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

Як правильно поводитися з секретами

Секрети завдають більше непотрібної шкоди, ніж будь-що інше, тож ось правила в одному місці:

• Ніколи не вставляйте справжній ключ у чат. Чати зберігаються, пересилаються і знімаються на скріншоти. Натомість покладіть ключі в секрети або змінні середовища вашого інструменту. (Що таке змінні середовища та секрети.)
• Викликайте платні сервіси з сервера. Браузер звертається до вашого сервера; сервер викликає сервіс ШІ чи платежів із ключем.
• Використовуйте окремі ключі для тестування і для роботи з реальними даними, щоб витеклий тестовий ключ не міг торкнутися реальних грошей.
• Встановіть ліміти витрат в панелях провайдерів ШІ та email.
• Негайно замініть ключ, якщо думаєте, що він витік. Створіть новий, оновіть секрет, а потім видаліть старий.

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

Скільки перевірки коду потрібно?

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

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

Корисний промпт навіть без розробника:

Простими словами поясни, як цей застосунок визначає, хто є користувачем, і що він має право бачити. Вкажи на файли. Потім перелічи все, що ти хотів би, щоб перевірив фахівець з безпеки.

Наш посібник про як переглядати код, згенерований ШІ пояснює, на що звертають увагу рецензенти, і його можна передати тому, хто проводитиме перевірку. Якщо ваш інструмент дозволяє експортувати код або синхронізувати з GitHub, організувати таку перевірку легко; у Mythex обидві можливості входять до Pro.

30-хвилинна перевірка перед публікацією

Проведіть її, перш ніж поділитися посиланням з кимось поза вашим колом.

Доступ (10 хвилин)

1. Два облікові записи, два браузери: чи може B відкрити записи A за URL? Не повинен.
2. Вийдіть з облікового запису і відвідайте адресу кожної сторінки напряму. Приватні сторінки мають перенаправляти на вхід.
3. Під звичайним користувачем відкрийте адміністративні адреси. Їх мають відхиляти.

Секрети (5 хвилин)

1. За допомогою промпту вище запитайте ШІ, де зберігається кожен ключ.
2. Відкрийте застосунок, перегляньте код сторінки і пошукайте «key», «secret» і «token».

Форми та зловживання (5 хвилин)

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

Дані та відновлення (5 хвилин)

1. Знайте, де зберігаються дані і як їх відновити.
2. Перевірте, що можна відкотити код до попередньої робочої версії.

Юридичні питання та основи (5 хвилин)

1. Якщо ви збираєте персональні дані, додайте політику конфіденційності і вкажіть, що саме збираєте. Див. як написати умови використання та політику конфіденційності.
2. Переконайтеся, що опублікований застосунок використовує HTTPS. Більшість конструкторів, зокрема Mythex, роблять це за вас.

Якщо все пройшло, ви готові до раннього запуску. Повторюйте кроки 1–5 після кожної великої зміни входу, ролей або даних.

Що платформи вайб кодингу захищають, а що ні

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

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

Коротка відповідь

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

Запитання