Безпека застосунку, створеного з ШІ: чек-лист перед запуском

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

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

1–3. Секрети й API-ключі

1. Жодних секретних ключів у фронтенд-коді. Усе, що потрапляє в браузер, — публічне. Пошукай у зібраному JavaScript рядки на кшталт sk_, secret, service_role, api_key. Секретні ключі живуть на сервері чи в serverless-функції та читаються зі змінних середовища.
2. Жодних секретів у Git. Додай .env у .gitignore ще до першого коміту. Безкоштовні secret scanning і push protection на GitHub допомагають ловити помилки в публічних репозиторіях.
3. Заміни все, що «витекло». Якщо ключ колись був закомічений або потрапив у браузер — відклич його й створи новий. Видалення з останнього коміту не прибирає його з історії.

4–5. Правила доступу до бази даних

4. Увімкни правила доступу для кожної таблиці. Хмарні бази на кшталт Supabase чи Firebase задумані так, щоб до них звертались із браузера з публічним ключем; захист — у правилах. У Supabase це row level security на кожній таблиці з політиками, у Firebase — правила безпеки, які не дозволяють «усе всім».
5. Перевір як стороння людина. Відкрий застосунок у приватному вікні, зареєструйся новим користувачем і спробуй прочитати чи змінити чужі дані, підмінивши ID у запиті. Якщо вийшло — правила неправильні.

6–8. Авторизація та адмінка

6. Перевіряй права на сервері, а не лише в інтерфейсі. Сховати кнопку адміністратора — не захист. Кожен запит, що змінює дані, має перевіряти, хто його надсилає.
7. Жодних «секретних» адмін-адрес. Сторінку /admin без посилань знаходять швидко. Закрий її справжнім входом і перевіркою ролей.
8. Використовуй перевірений сервіс авторизації замість саморобної системи паролів. Більшість хмарних баз і фреймворків мають його безкоштовно.

9–10. Форми, завантаження та оплати

9. Вважай будь-які вхідні дані ворожими. Перевіряй їх на сервері, обмежуй розмір і типи файлів, додай захист від спаму й ліміти запитів для публічних форм.
10. Довір картки платіжному провайдеру. Використовуй готові платіжні сторінки провайдера (наприклад, LiqPay, WayForPay чи Stripe) і перевіряй підпис вебхуків оплати. Ніколи не вважай замовлення оплаченим лише зі слів браузера.

11–12. Оновлення та резервні копії

11. Оновлюй залежності. Увімкни безкоштовні автоматичні сповіщення про вразливості в залежностях і регулярно оновлюйся; ШІ інколи пропонує застарілі пакети.
12. Май резервну копію та шлях назад. Знай, як відновити базу й відкотитися до попереднього деплою. Перевір це один раз заздалегідь.

Нехай ШІ перевірить власну роботу

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

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

• Жодних секретних ключів у фронтенді чи історії Git
• Ключі, що «витекли», замінені
• Правила доступу увімкнені й перевірені для кожної таблиці
• Права перевіряються на сервері для кожного запису
• Адмінка за справжньою авторизацією
• Серверна валідація, ліміти завантажень і захист форм від спаму
• Платіжні сторінки провайдера й перевірені вебхуки
• Сповіщення про вразливості ввімкнені, резервна копія й відкат перевірені

У програмі Ship Index Grow третій тиждень присвячений створенню з ШІ та безпечному запуску на власному домені. Повний шлях — у статті як створити й запустити продукт із ШІ за 6 тижнів.

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

Чи небезпечний код, написаний ШІ?

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

Де мають зберігатися API-ключі у вебзастосунку?

Секретні ключі — лише на сервері, у serverless-функції або в налаштуваннях секретів хостингу, ніколи у фронтенд-коді чи публічному репозиторії. У браузері можуть бути лише ключі, задумані як публічні, наприклад publishable чи anon key, захищений правилами бази даних.

Що таке row level security?

Row level security (RLS) — функція бази даних у Supabase та PostgreSQL, яка визначає, які рядки кожен користувач може читати чи змінювати. Без неї будь-хто з твоїм публічним ключем часто може прочитати або змінити всі дані.

Що робити, якщо ключ потрапив у відкритий доступ?

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