EVERYTHING
Кінцівка січня 2026 року. Розробник за вихідні створює соціальну мережу, використовуючи не традиційний код, а лише промпти та візію, покладаючись на ШІ. Платформа швидко стає вірусною. Andrej Karpathy, співзасновник OpenAI, назвав це «найбільш неймовірною реччю, що нагадує наукову фантастику». Але невдовзі дослідник безпеки відкриває інструменти розробника браузера і виявляє API-ключ у чистому JavaScript — доступний будь-кому, хто знає, як натиснути F12. За допомогою цього ключа він запитує виробничу базу даних без жодного входу чи спеціальних інструментів. У результаті з'являється 1.5 мільйона токенів аутентифікації API, 35 тисяч електронних адрес та тисячі приватних повідомлень. Весь застосунок — кожен агент, кожна облікова записана інформація, кожна розмова — залишався повністю відкритим.
Ілюзія функціональності: що насправді відбувається
Кілька років тому створення програмного забезпечення вимагало подолання болісного бар'єру: потрібно було вивчати синтаксис, фреймворки, бази даних, API, Git та багаторазово ламати код. Для більшості людей поза технологічною сферою інженерія ПЗ здавалася зачиненою кімнатою з дуже маленькими дверима. Згодом на сцену вийшов ШІ. Тепер людина з невеликим традиційним досвідом програмування може створити SaaS-застосунок протягом вихідних, підключити базу даних до фронтенду, інтегрувати платежі та розгорнути API — і все це лише за допомогою промптів. Цей перехід є значущим і примітним. Захоплення від того, як ідея перетворюється на робочий продукт швидше, ніж будь-коли раніше, є цілком зрозумілим.
Чому ШІ не може замінити досвід
Але навколо програмного забезпечення, згенерованого за допомогою ШІ, формується небезпечна ілюзія: якщо застосунок працює, він безпечний. Це дві різні речі. Дуже гарно спроектований застосунок все одно може викрити приватні дані користувачів, виточити API-ключі, дозволити несанкціонований доступ та випадково відключити захист бази даних — і все це при тому, що інтерфейс виглядає бездоганно, а процес входу працює ідеально. Проблеми безпеки завжди ховаються під видимою функціональністю.
Що ШІ робить добре, а що пропускає
ШІ дуже ефективний у допомозі з «щасливим шляхом» — коли функція працює, кнопка реагує, API повертає дані, сторінка відображається. Ця частина є примітною. Однак безпека існує в «нещасних шляхах»: що станеться, якщо хтось запитає базу даних без входу? Що робити, якщо зловмисник маніпулює запитом із браузера? Чи можуть API-ключі бути видимі у вихідному коді сторінки? Або якби хтось викликав кінцевий ендпоінт десять тисяч разів поспіль?
Аналіз Moltbook: що пішло не так
Moltbook був створений на Supabase — популярній, добре документованій службі бекенду, яка чудово підходить для швидкої розробки. Supabase призначений для роботи з публічним API-ключем, який відкритий на клієнтському боці. Це є навмисним рішенням і не є самостійною помилкою безпеки. Справжня проблема полягала у тому, як був налаштований цей ключ. Supabase має функцію Row-Level Security.
Перспективи та висновки
ШІ значно скорочує терміни реалізації. Однак він не зменшує досвіду, необхідного для постановки правильних питань щодо безпеки. Ця прогалина — саме там відбуваються збої. Важливо розуміти: це не лише проблема новачків. Навіть досвідчені розробники можуть стати надто впевненими, коли ШІ прискорює швидкість виведення продукту. Тому навіть якщо застосунок функціонально ідеальний, завжди необхідно вручну перевіряти всі «нещасні шляхи» та забезпечувати належний захист даних.
