Инцидент с утечкой данных Moltbook: Когда виб-кодинг становится кошмаром безопасности

Что на самом деле произошло в Moltbook?

Давайте разберёмся, что именно пошло не так, потому что детали имеют значение.

Moltbook был создан с использованием Supabase — популярной альтернативы Firebase с открытым исходным кодом, которая предоставляет хостинг баз данных PostgreSQL. Supabase стал бэкендом по выбору для приложений, созданных с помощью виб-кодинга, потому что он обрабатывает аутентификацию, базы данных и хранение с минимальной конфигурацией.

Проблема в том, что кто-то (или какой-то ИИ) поместил ключ API Supabase прямо в клиентский JavaScript-код. Это фундаментальная ошибка безопасности. Ключи API должны быть на сервере, никогда не в коде, который работает в браузере пользователя.

Но становится еще хуже.

Этот ключ API имел полный доступ на чтение и запись ко всей базе данных. И Moltbook не включил Row Level Security (RLS) — функцию Supabase, которая контролирует, кто может получить доступ к каким данным. RS — такая же опция, как ремень безопасности. Вы можете думать, что он вам не нужен, пока не произойдёт авария.

Исследователи безопасности Wiz нашли раскрытый ключ за минуты после просмотра сайта. Они могли бы:

• Скачано все 1,5 миллиона API-ключей (включая ключи для OpenAI, Anthropic и других провайдеров ИИ)
• Доступ к личным сообщениям между ИИ-агентами
• Изменены или удалены какие-либо данные в базе данных
• Взял под контроль любой пользовательский аккаунт
• Накопите огромные счета, используя украденные API-ключи

Самое смешное? Фаундер признался, что "полностью вайб-кодил" всю платформу. Никакого код-ревью. Никакого аудита безопасности. Только промпты к ИИ и копипаст результатов.

Почему это продолжает происходить

Вот что раздражает в этой истории: это не уникально.

Помните, когда у DeepSeek были раскрыты ключи API? Или Base44? Паттерн повторяется, потому что философия виб-кодирования активно discourages практики, которые предотвращают эти нарушения.

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

Но производственные приложения живут в другом мире. Они обрабатывают реальные данные пользователей, реальные платежи, реальные угрозы безопасности. То же мышление, которое помогает вам выпустить прототип за выходные, приведет к взлому вашего производственного приложения в первый день.

Я поговорил с исследователем в области безопасности, специализирующимся на коде, сгенерированном ИИ. Вот что его беспокоит:

• Непонимание того, что происходит: когда вы просите ИИ «создать систему входа», вы получаете код, который выглядит как система входа, но может содержать тонкие ошибки, которые заметит только эксперт
• Доверие к ИИ: Пользователи предполагают, что код, сгенерированный ИИ, безопасен, потому что... это от ИИ? Это предположение совершенно неверно
• Отсутствие основ: Кодеры вибрации часто не знают, чего они не знают о безопасности

Проблема 45%

Позвольте дать вам цифру, которая должна не давать вам спать ночью: 45%.

Это процент кода, сгенерированного ИИ, который содержит уязвимости безопасности, согласно исследованию Veracode по безопасности ПО, сгенерированного ИИ^[1].

Это не про плохие AI-модели или неспособных разработчиков. Это про фундаментальную природу генерации кода. AI-модели обучены на существующем коде — который включает небезопасный код. Они воспроизводят паттерны, которые видели, включая уязвимые.

Распространённые уязвимости в коде, сгенерированном ИИ, включают:

Утечка Moltbook была на самом деле двумя проблемами: захардкоженным API-ключом (hardcoded secrets) И отсутствием RLS (небезопасная конфигурация). Каждая одна была бы плоха. Вместе они создали катастрофу.

О том, чего не говорят о vibe coding

Буду с вами честен. Я написал множество проектов с помощью vibe coding. Это действительно изменило мой подход к разработке. Но я также извлёк немало жёстких уроков.

Вы по-прежнему должны понимать безопасность

Неудобная правда: вы не можете использовать ИИ-инструменты для создания безопасных приложений, если сами не понимаете безопасность. ИИ не знает вашу модель угроз. Он не знает, какие активы вы защищаете. Он просто генерирует код, который выглядит разумно.

Вам не нужно становиться экспертом по безопасности. Но вам нужно понимать:

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

Прототипируйте быстро, затем проектируйте

Мой текущий рабочий процесс:

• Vibe-кодинг прототипа — Получите работающий вариант, проверьте идею с реальными пользователями
• Определите соответствие продукта рынку — Прежде чем инвестировать что-либо
• Рефакторьте для продакшена — Вот где вы реально инженерно обеспечиваете безопасность, производительность и поддерживаемость

Ошибка в отправке прототипов, созданных на «вибах», напрямую в продакшен без этапа рефакторинга. Вы не экономите время — вы накапливаете технический долг, который обойдется вам позже.

Используйте правильный инструмент для задачи

Это может быть спорно, но я не думаю, что вайб-кодинг уместен для:

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

Для внутренних инструментов, 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 ключи клиенту
• [ ] Внедрите правильную проверку ввода на всех пользовательских вводах
• [ ] Настройте ограничение скорости для предотвращения злоупотреблений
• [ ] Пройдите тест на проникновение перед запуском чего-либо с реальными пользователями

Инструменты, которые помогают

Что это значит для индустрии

Я искренне обеспокоен тем, куда мы движемся.

Мы находимся в midst огромного сдвига в том, как создаётся ПО. Нетехнические основатели теперь могут создавать сложные приложения. Барьер входа рухнул. Это действительно захватывающе.

Но мы также создаём поколение приложений, за которыми никто не следит в магазине.

Вот что, по моему мнению, должно произойти:

• Инструменты ИИ для программирования нуждаются в более безопасных настройках по умолчанию — перестаньте генерировать код с встроенными уязвимостями
• Об этом нужно говорить чаще — В каждом посте о vibe coding следует упоминать безопасность
• Нам нужны лучшие инструменты — Автоматическое сканирование безопасности должно быть встроено в каждый рабочий процесс кодирования с ИИ
• Основатели должны брать ответственность — нельзя винить ИИ, когда что-то идёт не так

Будущее разработки ПО — не в выборе между скоростью ИИ и безопасностью. Это в том, чтобы научиться использовать оба вместе.

Часто задаваемые вопросы

Итог

Moltbook — не аномалия. Это предварительный взгляд на то, что грядет.

По мере того как всё больше основателей выпускают приложения, созданные с помощью vibe coding, без понимания основ безопасности, мы увидим больше утечек. Больше скомпрометированных API-ключей. Больше открытых баз данных. Больше жертв.

Это не аргумент против vibe coding. Это аргумент за честность о его ограничениях.

Разрабатывайте быстро. Проверяйте идеи. Двигайтесь быстро. Но прежде чем вы поставите под угрозу реальные данные пользователей, замедлитесь и сделайте работу по безопасности. Ваши пользователи доверяют вам свою информацию. Это доверие не должно быть vibe-coded away.

Похожие публикации

• Что такое Vibe Coding? Полное руководство 2026
• Cursor vs Windsurf для Vibe Coding: что побеждает в 2026?
• Как создать приложение на ИИ за 7 дней (пошагово)
• Как быстро получить 100 бета-пользователей

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

Источники

Оригинально опубликовано на Блоге GetFree.APP — Последнее обновление: 17 февраля 2026 г.