The Moltbook Breach: When Vibe Coding Becomes a Security Nightmare

Що справді сталося з Moltbook?

Давайте розберемося, що саме пішло не так, бо деталі мають значення.

Moltbook було створено з використанням Supabase — популярної альтернативи Firebase з відкритим кодом, яка надає хостиngовані бази даних PostgreSQL. Supabase став вибором бекенду для додатків, створених за допомогою vibe coding, оскільки він обробляє автентифікацію, бази даних і сховище з мінімальною налаштовуванням.

Проблема? Хтось (або якийсь AI) вставив ключ Supabase API безпосередньо у клієнтський JavaScript-код. Це фундаментальна помилка безпеки. Ключі API належать серверу, ніколи не потрапляйте у код, що запускається у браузері користувача.

Але стає гірше.

Тому що цей API-ключ мав повний доступ на читання та запис до всієї бази даних. І Moltbook не увімкнув Row Level Security (RLS) — функцію Supabase, яка контролює, хто може отримати доступ до яких даних. RLS така ж необов'язкова, як ремінь безпеки. Ви можете думати, що він вам не потрібен, поки не станеться аварія.

Дослідники безпеки з Wiz знайшли відкритий ключ за лічені хвилини після перегляду веб-сайту. Вони могли б:

• Завантажено 1,5 мільйона API-ключів (включаючи ключі для OpenAI, Anthropic та інших постачальників ШІ)
• Доступ до приватних повідомлень між агентами ШІ
• Змінено або видалено будь-які дані в базі даних
• Перехоплення будь-якого облікового запису користувача
• Створити величезні рахунки за допомогою викрадених API-ключів

А фішка в тому, що засновник визнав, що «повністю створив платформу на вібі». Без рев'ю коду. Без аудиту безпеки. Просто промпти до ШІ та копіювання результатів.

Чому це продовжується

Ось що дратує в цій історії: вона не унікальна.

Пам'ятаєте, як DeepSeek мали свої API-ключі відкритими? Або Base44? Цей паттор повторюється, тому що філософія vibe coding активно заваджає практикам, які запобігають цим порушенням.

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

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

Я розмовляв із дослідником безпеки, який спеціалізується на коді, створеному ШІ. Ось що не дає йому спати:

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

Створення архітектури рівнів підписки

Дайте мені число, яке не дає вам спати: 45%.

Це відсоток коду, створеного ШІ, який містить вразливості безпеки, згідно з дослідженням Veracode щодо безпеки програмного забезпечення, створеного ШІ^[1].

Це не погані моделі ШІ чи некомпетентні розробники. Це стосується фундаментальної природи генерації коду. Моделі ШІ навчені на існуючому коді — який включає небезпечний код. Вони відтворюють патерни, які бачили, включаючи вразливі.

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

Утеча даних у Moltbook була фактично двома проблемами: закодований у коді API-ключ (закриті секрети) та відсутність RLS (небезпечна конфігурація). Кожна з цих проблем окремо була б серйозною. Разом вони створили катастрофу.

Те, про що не каже ніхто, щодо vibe coding

Буду чесним з вами. Я створив багато проєктів за допомогою vibe coding. Це справді змінило мій підхід до розробки. Але я також вивчив багато важких уроків.

Ви все ще потребуєте розуміння безпеки

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

Вам не потрібно стати експертом з безпеки. Але ви маєте розуміти:

• Ніколи не розміщуйте секрети у клієнтському коді
• Завжди увімкніть Row Level Security у базах даних
• Використовуйте змінні середовища для чутливої конфігурації
• Впровадити належну валідацію введення
• Проводьте сканування безпеки згенерованого коду

Швидке прототипування, потім інженерія

Мій поточний робочий процес:

• Створіть прототип за допомогою Vibe code — отримайте щось працююче, підтвердіть ідею реальними користувачами
• Визначте відповідність продукт–ринок — Ще до інвестування чогось
• Рефакторинг для продакшну — Це те, де ви фактично інженеруєте безпеку, продуктивність і зручність супроводу

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

Використовуйте правильний інструмент для роботи

Можливо, це суперечливо, але я не думаю, що vibe coding підходить для:

• Додатки, які обробляють чутливі дані користувачів (охорона здоров'я, фінанси)
• Системи, що обробляють платежі
• Все, що має вимоги до регуляторного відповідності
• Додатки, де збій безпеки може спричинити реальну шкоду

Для внутрішніх інструментів, MVP і прототипів? Будьте сміливими. Для продуктивних систем, що обробляють реальні дані користувачів? Проінженерйте це належним чином.

Як захистити себе

Якщо ви все одно vibe coding (і чесно кажучи, вам слід — це надзвичайно потужний інструмент), ось як уникнути стати наступним заголовком:

Для вашого Supabase/Backend

javascript
// WRONG - Never do this
const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE')
// Your service_role key is also exposed here!

// CORRECT - Use environment variables, server-side only
const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_ANON_KEY
)

Основний чек-лист безпеки

• [ ] Увімкніть Row Level Security на ВСІХ таблицях бази даних
• [ ] Зберігайте ключі API у змінних середовища, ніколи в коді
• [ ] Запустіть сканування безпеки всього згенерованого коду (Snyk, CodeQL або GitHub Advanced Security)
• [ ] Ніколи не надавайте ключі service_role клієнту
• [ ] Впровадте належну валідацію введення для всіх користувацьких введень
• [ ] Налаштуйте обмеження швидкості, щоб запобігти зловживанню
• [ ] Отримайте тест на проникнення перед запуском чогось із реальними користувачами

Інструменти, які допоможуть

Що це означає для індустрії

Я справді стурбований тим, куди ми рухаємось.

Ми знаходимося посеред масивного зсуву у тому, як створюється ПЗ. Нетехнічні засновники тепер можуть створювати складні програми. Бар'єр входу розпався. Це справді захватююче.

Але ми також створюємо покоління програм, за якими ніхто не спостерігає в магазині.

Ось що, на мою думку, має статися:

• Інструменти кодування на основі ШІ потребують кращих стандартів безпеки — Припиніть генерувати код із вбудованими вразливостями
• Спільнотам потрібно більше говорити про це — у кожному дописі блогу про vibe coding слід згадувати безпеку
• Нам потрібні кращі інструменти — Автоматичне сканування безпеки має бути вбудоване в кожний робочий процес написання коду з ШІ
• Засновники мають нести відповідальність — Ви не можете звинуватити AI, якщо щось піде не так

Майбутнє розробки ПЗ — не вибір між швидкістю ШІ та безпекою. Це вміння використовувати обидва разом.

Найчастіші запитання

Підсумок

Moltbook — не аномалія. Це попередній погляд на те, що чекає нас.

Чим більше засновників випускають додатки, створені за допомогою vibe coding, не розуміючи основ безпеки, тим більше ми побачимо зламів. Більше витоків API-ключів. Більше відкритих баз даних. Більше жертв.

Це не аргумент проти vibe coding. Це аргумент за чесність щодо його обмежень.

Швидко. Тестуйте ідеї. Рухайтеся швидко. Але перед тим, як поставити реальні дані користувачів під загрозу, уповільніться і зробіть роботу з безпекою. Ваші користувачі довіряють вам свою інформацію. Цю довіру не варто втратити через vibe coding.

Пов’язані публікації

• Що таке Vibe Coding? Повний гід 2026
• Cursor vs Windsurf для Vibe Coding: Що перемагає в 2026?
• Як створити додаток на ШІ за 7 днів (Покроково
• Як швидко отримати 100 бета-користувачів

Готові безпечно запустити свій додаток? Опублікуйте свій додаток на GetFree — курованому каталозі, де розробники діляться промокодами та бета-доступом із тисячами цільових тестувальників.

Джерела

Спершу опубліковано на блоґі GetFree.APP — Останнє оновлення: 17 лютого 2026