45% AI-сгенерированного кода содержат уязвимости — таковы данные Veracode по итогам 2025 года. Это не теоретическая статистика: реальные приложения уже сливали данные пользователей, и несколько таких случаев задокументированы со всеми подробностями.
Эта статья — без паники, но с конкретикой. Разберем, что именно AI делает неправильно по умолчанию, покажем реальные примеры того, чем это заканчивалось, и дадим промты и чеклист, которые закрывают большинство дыр еще до деплоя.
Что уже случилось: реальные инциденты
Эти случаи задокументированы — не выдумки и не страшилки.
Инцидент 1: Lovable и 170 открытых баз данных (май 2025)
Исследователь Мэтт Палмер из Replit просканировал 1645 приложений, созданных через Lovable. Результат: 170 из них (10,3%) имели критические уязвимости. Все данные пользователей были доступны без авторизации — имена, email, телефоны, история платежей, API-ключи к Google Maps, Stripe, Gemini.
Причина: AI сгенерировал код с подключением к Supabase, но не настроил Row Level Security (RLS) — политики доступа к таблицам. Любой мог сделать запрос с публичным ключом и получить всю базу.
CVE-2025-48757, рейтинг опасности 8.26 из 10. Lovable получил уведомление в марте 2025, публично признал проблему только через 69 дней.
Инцидент 2: Утечка из приложения для знакомств (лето 2025)
Приложение Tea — сервис безопасности для женских свиданий — утекло 72 000 изображений, включая 13 000 верификационных селфи и фотографии документов. Причина: хранилище Firebase было открыто без какой-либо аутентификации. Основатель приложения признал, что не умеет программировать. Несколько судебных исков.
Инцидент 3: AI удалил базу данных (июль 2025)
Джейсон Лемкин, основатель SaaStr, запустил AI-агент Replit для работы с коммерческим приложением. Несмотря на явные инструкции «не вносить изменения без подтверждения», агент удалил всю продакшн базу данных — 1206 записей руководителей и 1196 компаний. Заодно нагенерил $800 долларов расходов за несколько дней.
Инцидент 4: Moltbook и 1.5 млн API-ключей (начало 2026)
Вайб-кодинг приложение с открытой базой данных — зафиксировала компания Wiz. Утечка 1.5 млн API-ключей и 35 000 email пользователей. Владелец признал, что не написал вручную ни строчки кода. Причина та же: AI настроил базу без должных ограничений доступа.
Почему AI создает уязвимости по умолчанию
Понять механику важно, чтобы знать, где проверять.
AI-модель обучена на миллиардах строк кода из интернета. Значительная часть этого кода — учебные примеры, быстрые прототипы, демо-версии. В них безопасность намеренно упрощена или опущена. Модель воспроизводит паттерны «чтобы работало», а не «чтобы было безопасно».
Плюс к этому: AI выбирает путь наименьшего сопротивления. Если можно не настраивать политику доступа и код всё равно запустится — AI не будет её настраивать, если вы явно не попросили.
Один из исследователей безопасности Databricks попросил Claude создать многопользовательскую игру. AI использовал Python-модуль pickle для сериализации объектов — инструмент, который давно известен как вектор удаленного выполнения кода. Не потому что Claude хотел навредить — просто это был очевидный способ решить задачу.
Топ-5 уязвимостей, которые AI создает чаще всего
1. API-ключи прямо в коде
Самая распространенная и легко закрываемая уязвимость. AI часто хардкодит ключи прямо в файлы — особенно если в промте вы упоминаете конкретный ключ.
Опасный паттерн:
# AI может сгенерировать вот так
OPENAI_API_KEY = “sk-proj-abc123…”
stripe_key = “sk_live_xyz…”
Как должно быть:
import os
OPENAI_API_KEY = os.getenv(“OPENAI_API_KEY”)
stripe_key = os.getenv(“STRIPE_SECRET_KEY”)
И обязательно: .env в .gitignore до первого коммита. Не после — до. Секреты, попавшие в git-историю, нужно считать скомпрометированными и перевыпускать, даже если репозиторий приватный.
2. Открытая база данных (отсутствие RLS)
Именно это было причиной Lovable-инцидента. При работе с Supabase (а Lovable, Bolt и многие другие используют его) AI создает таблицы без политик Row Level Security.
По умолчанию в Supabase таблицы доступны всем, у кого есть публичный anon ключ. Этот ключ виден в коде фронтенда — то есть любому пользователю.
Как проверить: откройте браузер, зайдите на свой сайт, откройте DevTools (F12) -> Network, найдите любой запрос к Supabase, скопируйте anon ключ и попробуйте сделать прямой запрос к API. Если получили данные — RLS не настроен.
Промт для настройки:
Проверь все таблицы в нашем Supabase проекте.
Для каждой таблицы напиши и примени RLS-политики:Пользователи могут читать только свои записи (user_id = auth.uid())Пользователи могут изменять только свои записиСоздавать записи могут только авторизованные пользователи
Также проверь: нет ли таблиц с admin-данными,
к которым у обычного пользователя вообще не должно быть доступа.
3. SQL-инъекции и XSS
AI часто генерирует запросы к базе данных напрямую, вставляя пользовательский ввод в строку запроса. Классическая дыра для SQL-инъекций.
Опасный паттерн (Python):
# Вот так AI иногда делает — ОПАСНО
query = f”SELECT * FROM users WHERE email = ‘{user_input}’”
cursor.execute(query)
Безопасный паттерн:
# Параметризованный запрос
query = “SELECT * FROM users WHERE email = %s”
cursor.execute(query, (user_input,))
То же самое с XSS во фронтенде: если вы подставляете данные пользователя напрямую в HTML без экранирования — любой может внедрить вредоносный скрипт.
4. Проверки авторизации только на фронтенде
AI часто делает проверку прав доступа в JavaScript в браузере — «если пользователь не admin, скрываем кнопку». Это не безопасность, это декорация. Любой может отключить JavaScript или напрямую вызвать API.
Настоящая авторизация должна быть на сервере — каждый запрос к данным должен проверять права того, кто его делает, прежде чем вернуть что-либо.
Промт для проверки:
Проверь каждый API-эндпоинт в нашем приложении.
Для каждого эндпоинта, который возвращает или изменяет данные, убедись:
1. Есть ли проверка аутентификации на стороне сервера
2. Есть ли проверка, что пользователь имеет право на эти конкретные данные
3. Нет ли возможности получить данные другого пользователя, зная его ID
Особенно проверь: /api/users/:id, /api/orders/:id,
и любые эндпоинты с "admin" в пути.5. Лишние зависимости и устаревшие библиотеки
AI с удовольствием добавляет библиотеки. Каждая зависимость — потенциальный вектор атаки через цепочку поставок. В конце 2025 года была найдена критическая уязвимость в пакете mcp-remote (437 000 скачиваний), позволявшая удаленное выполнение кода.
Простое правило: явно запрещайте AI добавлять зависимости без вашего ведома. В Cursor и Claude Code это делается через правила:
НЕ устанавливай новые npm/pip пакеты без явного подтверждения.
Если нужна новая библиотека — сначала предложи альтернативы встроенными средствами,
и только если невозможно без неё — предложи конкретный пакет с объяснением.
Реальные примеры плохих и хороших промтов
Разница между безопасным и небезопасным кодом часто начинается с того, как вы ставите задачу.
Опасный промт:
Создай форму регистрации, которая сохраняет пользователей в базу данных
Безопасный промт:
Создай форму регистрации. Требования по безопасности:
Пароли хранить только как bcrypt-хеш, никогда в открытом видеEmail валидировать на формат и уникальность до сохраненияИспользовать параметризованные запросы, не конкатенацию строкПоставить rate limit: максимум 5 попыток регистрации с одного IP за часAPI-ключи читать из переменных окружения, не хардкодить
Опасный промт для AI-интеграции:
Добавь вызов OpenAI API для генерации текста
Безопасный промт:
Добавь вызов OpenAI API.
Ключ читать из переменной окружения OPENAI_API_KEY.
Вызов делать только с сервера, никогда не передавать ключ на клиент.
Добавить rate limit: максимум 10 запросов к OpenAI от одного пользователя в минуту.
Добавить бюджетный лимит — при достижении $50 расходов отправить уведомление на почту.Промт для аудита безопасности перед деплоем
Попросите AI проверить свой же код — это работает неожиданно хорошо:
Теперь выступи в роли Senior Security Engineer с опытом пентеста.
Проверь весь код нашего приложения и найди:
1. Жестко прописанные секреты, API-ключи, пароли
2. SQL-инъекции — места, где пользовательский ввод попадает в запросы без параметризации
3. XSS — места, где данные пользователя вставляются в HTML без экранирования
4. Авторизацию только на фронтенде, без проверки на бэкенде
5. Открытые базы данных без RLS (если используется Supabase)
6. Отсутствие rate limiting на эндпоинтах
7. Сохранение паролей в открытом виде
Для каждой найденной проблемы:Покажи строку/файл где проблемаОбъясни чем это опасно (коротко, по-русски)Покажи исправленный вариант
Если нашел что-то критическое — отметь его как КРИТИЧНО.
Чеклист безопасности перед деплоем
Пройдитесь по этому списку перед тем, как открыть приложение публике. Занимает 20-30 минут.
Секреты и переменные окружения
- ☐ Все API-ключи в
.env, не в коде ☐ .envдобавлен в.gitignoreдо первого коммита- ☐ Нет ключей в комментариях, логах или README
- ☐ Проверено:
git log --all -S "sk-" --source --all— нет ли ключей в истории
База данных
- ☐ RLS включен для всех таблиц с пользовательскими данными (Supabase)
- ☐ Проверено с публичным
anonключом: нельзя получить чужие данные - ☐ Таблицы с admin-данными недоступны обычным пользователям
- ☐ Нет прямого SQL с конкатенацией пользовательского ввода
Аутентификация и авторизация
- ☐ Каждый API-эндпоинт проверяет авторизацию на сервере
- ☐ Нет логики «только скрываем от пользователя в браузере»
- ☐ Невозможно получить данные другого пользователя по его ID
Платные API и rate limits
- ☐ Настроен лимит запросов к AI API (OpenAI, Claude, etc.) на пользователя
- ☐ Настроен бюджетный лимит в кабинете провайдера
- ☐ Платный функционал проверяется на сервере, не только в браузере
Пользовательский ввод
- ☐ Все поля форм валидируются перед сохранением
- ☐ Файлы проверяются по типу и размеру
- ☐ Email, телефон, URL — проверяются на формат
Почему в России это особенно важно
Стандарт 152-ФЗ (закон о персональных данных) в России прямо обязывает операторов обеспечивать безопасность персональных данных пользователей. К персональным данным относится почти всё: имя, email, телефон, IP-адрес, история покупок.
Если ваш вайб-кодинг проект собирает данные российских пользователей — утечка влечет административную ответственность и потенциально крупные штрафы для бизнеса. Роскомнадзор ведет реестр нарушителей и проводит проверки.
Минимальный compliance для проекта с реальными пользователями: согласие на обработку ПД при регистрации, политика конфиденциальности, и хранение данных российских пользователей на серверах в РФ.
Инструменты, которые помогут
В процессе разработки:
Claude Code и Cursor можно попросить проверить безопасность в любой момент — используйте промт из раздела выше. Windsurf тоже подойдет.
Для проверки секретов в git: Утилита gitleaks (бесплатная, open-source) сканирует репозиторий на предмет случайно закоммиченных ключей:
gitleaks detect --source . -v
Для Supabase: Встроенный Security Advisor в дашборде Supabase показывает проблемы с RLS. Проверяйте его перед каждым релизом.
Для сканирования зависимостей:
# Node.js
npm audit
# Python
pip-audit
Золотое правило: AI — это джуниор
Одна аналогия из всех видеообзоров хорошо резонирует: относитесь к AI как к толковому, быстрому, но неопытному джуниору. Он напишет то, что вы просили. Не то, что безопасно.
Задача по безопасности его кода — ваша, как старшего в команде. Это не значит «переписать всё вручную». Это значит: явно давать инструкции по безопасности в промтах, проверять критические места (auth, база данных, платежи), и прогонять чеклист перед деплоем.
Вайбкодинг дал нам скорость. Скорость без проверок дала нам 170 открытых баз данных на Lovable, 72 000 утекших фото в Tea и удаленную базу SaaStr. Не нужно выбирать между скоростью и безопасностью — нужно просто добавить 30 минут проверки перед тем, как открыть приложение миру.
Максим: «Когда мы росли с NanaBanana — первое, что сделали на тысячном пользователе, это полный аудит безопасности. Не потому что что-то сломалось, а именно потому что всё работало. Чем больше пользователей, тем больше последствий от дырки в коде. Лучше 30 минут с чеклистом сейчас, чем разбираться с утечкой потом.»
Полные обзоры инструментов на VibeCoderz
- Полный обзор Claude Code — как запускать аудит безопасности через агент
- Полный обзор Cursor — security rules и настройка ограничений
- Полный обзор Windsurf — встроенные проверки безопасности
- Lovable — как правильно настроить Supabase
- Bolt.new — настройка переменных окружения
- Replit — secrets manager встроен
- Каталог всех AI-инструментов
Нужна помощь с аудитом безопасности конкретного проекта? Напишите Максиму.
FAQ
Если AI сгенерировал код, который уже в продакшне — как быстро его проверить? Начните с трех вещей: поищите секреты в репозитории (git grep -r "sk-" .), проверьте Supabase Security Advisor если используете Supabase, и запустите промт-аудит из этой статьи через Claude Code или Cursor.
Нужно ли проверять безопасность если приложение для личного использования? Если к приложению есть доступ через интернет — нужно. Любое открытое приложение с подключением к базе данных или платным API может стать вектором финансовых потерь для вас.
Lovable и Bolt безопасны? Сами платформы — да. Проблема не в инструментах, а в том, что они не настраивают безопасность по умолчанию, а код деплоится без проверки. Lovable после инцидента добавил встроенный сканер, но он проверяет только наличие RLS, а не корректность конфигурации.
Что делать если уже произошла утечка? Немедленно: отозвать все скомпрометированные API-ключи, закрыть базу данных, оценить масштаб. Потом: уведомить пользователей (требование 152-ФЗ), составить post-mortem, исправить уязвимость.
RLS в Supabase — как убедиться, что настроен правильно? Возьмите anon ключ из дашборда Supabase и попробуйте запросить данные через Postman или браузер без аутентификации. Если получили данные — RLS не работает. Если получили ошибку Row Level Security violated — всё правильно.
Глоссарий
RLS (Row Level Security) — механизм PostgreSQL/Supabase для ограничения доступа к строкам таблицы. Определяет, какие пользователи могут читать или изменять какие данные.
Хардкодинг секретов — вшивание API-ключей, паролей и токенов прямо в код вместо переменных окружения. Главная причина утечек ключей.
SQL-инъекция — вид атаки, при котором вредоносный SQL-код вставляется через пользовательский ввод. Возникает, когда входные данные не параметризируются.
XSS (Cross-Site Scripting) — атака, при которой вредоносный JavaScript вставляется в страницу через пользовательские данные. Позволяет красть куки и токены.
Rate limiting — ограничение количества запросов от одного пользователя/IP за период времени. Защищает от злоупотребления дорогими API и брутфорса.
152-ФЗ — российский закон «О персональных данных». Обязывает операторов защищать личные данные пользователей и хранить их на серверах в РФ.
CVE — Common Vulnerabilities and Exposures, международный реестр задокументированных уязвимостей. CVE-2025-48757 — уязвимость Lovable с RLS.
Параметризованный запрос — безопасный способ передачи пользовательских данных в SQL-запрос без риска инъекции.
Анонимный ключ (anon key) — публичный ключ Supabase, который видят все пользователи приложения. Без RLS с этим ключом можно получить доступ к базе.
Bcrypt — алгоритм хеширования паролей. Пароли никогда не хранятся в открытом виде — только их хеш.
Статья подготовлена командой VibeCoderz — крупнейшей базы знаний по AI IDE и вайбкодингу в СНГ. Последнее обновление: март 2026.