ИИ-конструкторы приложений превратили миллионы людей без инженерного образования в создателей софта. Только у Lovable около 8 млн пользователей и больше 200 тыс. новых проектов в день (TechCrunch). Многие такие приложения уже хранят реальные данные клиентов, принимают реальные платежи и управляют реальными процессами — от CRM-надстройки, которую руководитель продаж «быстро собрал за вечер», до клиентского кабинета небольшого онлайн-сервиса.
Неудобная правда: приложение, которое идеально работает на демо, может позволить любому залогиненному пользователю прочитать данные всех остальных — достаточно поменять одну цифру в запросе. Генераторы оптимизируют то, что видно на экране. Безопасность невидима, пока не сломается.
В этой статье — практический чек-лист аудита для приложений, собранных в Lovable, Bolt, Replit, Cursor и похожих инструментах: где такие приложения обычно ломаются, как проходит короткий аудит-«спасение» и как выбрать между исправлением, рефакторингом и переписыванием.
Масштаб проблемы в цифрах
Данные за 2025–2026 годы однозначны:
- 5 600 публичных приложений проверено — больше 2 000 серьёзных уязвимостей. Компания Escape также нашла 400 открытых секретов и 175 случаев утечки персональных данных (SoftwareSeni).
- CVE-2025-48757: у 170 из 1 645 проверенных приложений на Lovable данные были открыты, потому что была выключена Row Level Security (Cloud Security Alliance, The Next Web).
- Сами платформы тоже уязвимы. В апреле 2026 года из-за ошибки класса BOLA в самом Lovable чужой код и учётные данные баз 48 дней были доступны посторонним (The Next Web).
- 406 млн записей раскрыло приложение Chat & Ask AI из-за правила Firebase, которое разрешало всё всем (CSA).
- Около 55% ИИ-сгенерированного кода безопасно — по тестам Veracode, и эта доля не растёт, хотя модели становятся лучше (SoftwareSeni).
- 19,7% пакетов, которые предлагают модели, не существуют. Это подарок злоумышленникам: они регистрируют такие имена и подсовывают вредоносный код (так называемый slopsquatting) (CSA).
Это не значит, что инструменты бесполезны. Это значит, что сгенерированное приложение — черновик, который ещё ни разу не видел специалист по безопасности.
Где ломаются такие приложения: пять повторяющихся слабых мест
1. Правила доступа к базе данных
Многие конструкторы связывают фронтенд с Supabase или Firebase. Браузер обращается к базе напрямую с публичным ключом. Так и задумано — при условии, что правила доступа решают, кто может читать и менять каждую строку. В Supabase это Row Level Security (RLS) в Postgres, в Firebase — security rules. Если RLS на таблице выключена или правило по сути гласит «читать и писать можно всегда», таблица открыта любому, кто откроет консоль браузера.
Типичные находки: RLS включена на первых таблицах, но не на добавленных позже; политики проверяют «пользователь вошёл в систему», а не «это его запись»; хранилища с загруженными документами открыты публично; в браузер отдаётся ключ service role, который обходит все правила.
2. Авторизация в API
Аутентификация отвечает на вопрос «кто вы?». Авторизация — «можно ли вам трогать эту запись?». Сгенерированный код часто делает первое и забывает про второе. Результат называется BOLA (broken object level authorization): меняете /invoices/1042 на /invoices/1043 — и видите счёт чужого клиента. Неслучайно BOLA стоит на первом месте в OWASP API Security Top 10.
Второй шаблон — «безопасность через сокрытие»: кнопка администратора не видна обычным пользователям, но эндпоинт за ней роль не проверяет.
3. Секреты не на своём месте
API-ключи провайдеров моделей, секретные ключи платёжных систем и доступы к базе оказываются во фронтенд-бандле, в закоммиченных файлах окружения или в системном промпте ИИ-функции. Удалить ключ из последнего коммита недостаточно: в истории git он остаётся, пока его не перевыпустят.
4. Зависимости, которые никто не выбирал
Сгенерированные проекты подтягивают десятки пакетов. Часть устарела и содержит известные уязвимости, часть — вспомним 19,7% — модель выдумала, и их уже мог зарегистрировать кто-то другой. Без lock-файла и проверки зависимостей никто не знает, что на самом деле работает в продакшене.
5. Незащищённые ИИ-эндпоинты
Если приложение вызывает языковую модель, появляются два новых риска. Prompt injection: текст пользователя или загруженный документ содержит инструкции, которые перебивают ваши. Злоупотребление расходами: эндпоинт без ограничения частоты запросов и бюджетных лимитов позволяет кому угодно раздуть ваш счёт за модели. Методы защиты подробно разобраны в статье о prompt injection и безопасности агентов.
Самопроверка за 30 минут — до того, как звать специалистов
Самые опасные проблемы в собственном приложении можно найти самостоятельно:
- Откройте панель базы данных (Supabase, Firebase или аналог) и выпишите все таблицы и хранилища файлов. Отметьте, где включены правила доступа. Каждая таблица без правил — красный флаг.
- Поищите секреты в опубликованном фронтенде. Откройте сайт, в инструментах разработчика браузера посмотрите JavaScript-файлы и поищите строки вроде
sk_,secret,service_roleили префикс ключа вашего провайдера моделей. Публичный ключ типа anon или publishable — норма, секретный — нет. - Создайте два тестовых аккаунта. Войдите под первым, создайте запись и скопируйте её ID из адресной строки или вкладки «Сеть». Войдите под вторым и откройте этот ID. Если запись загрузилась — у вас проблема BOLA.
- Откройте страницы администратора под обычным пользователем, введя адрес вручную. Если что-то загрузилось — защита декоративная.
- Проверьте, кто видит загруженные файлы. Откройте ссылку на документ в приватном окне браузера. Если он открывается без входа — хранилище публичное.
- Загляните на страницу расходов у провайдера моделей. Необъяснимые всплески могут означать, что кто-то нашёл ваш ИИ-эндпоинт.
Если хоть одна проверка не пройдена — остановите разработку новых функций и сначала исправьте базу. Если пройдены все, полный чек-лист всё равно нужен: эти шесть тестов ловят самые громкие проблемы, но не все.
Чек-лист аудита: 24 пункта
Используйте таблицу как рабочий список. Критичность показывает типичные последствия, если пункт не выполнен.
| # | Область | Что проверить | Критичность |
|---|---|---|---|
| 1 | База данных | RLS (или аналогичные правила) включена на каждой таблице, в том числе добавленной позже | Критично |
| 2 | База данных | Политики проверяют владельца или роль, а не просто «вошёл в систему» | Критично |
| 3 | База данных | Отдельные политики на чтение, создание, изменение и удаление | Высокая |
| 4 | Хранилище | Хранилища с файлами пользователей закрыты; ссылки подписаны и ограничены по времени | Критично |
| 5 | Ключи | Ключи service role и администратора есть только на сервере | Критично |
| 6 | Авторизация | Каждый API-маршрут и серверная функция проверяют доступ именно к этой записи | Критично |
| 7 | Авторизация | Функции администратора защищены на сервере, а не просто скрыты в интерфейсе | Критично |
| 8 | Аутентификация | Сброс пароля, смена e-mail и приглашения не позволяют перехватить аккаунт | Высокая |
| 9 | Аутентификация | Сессии истекают; токены не хранятся там, где их без нужды читают скрипты | Средняя |
| 10 | Секреты | Во фронтенд-бандле нет секретных ключей (поиск по собранному JavaScript) | Критично |
| 11 | Секреты | История git просканирована; каждый засвеченный ключ перевыпущен, а не просто удалён | Критично |
| 12 | Секреты | В системных промптах нет ключей, внутренних адресов и конфиденциальных правил | Высокая |
| 13 | Зависимости | Каждый пакет существует, поддерживается и зафиксирован в lock-файле | Высокая |
| 14 | Зависимости | Проверка на известные уязвимости пройдена; есть перечень компонентов (SBOM) | Средняя |
| 15 | Ввод данных | Все входные данные проверяются на сервере; загрузки — по типу и размеру | Высокая |
| 16 | ИИ | Ответ модели считается недоверенным: никогда не исполняется и не подставляется напрямую в запросы | Высокая |
| 17 | ИИ | Ограничение частоты и месячные бюджетные лимиты на каждом эндпоинте с вызовом модели | Высокая |
| 18 | ИИ | Найденные документы и контент пользователей отделены от инструкций; тесты на инъекции проведены | Высокая |
| 19 | Веб | Только HTTPS, заголовки безопасности настроены, CORS ограничен своими доменами | Средняя |
| 20 | Эксплуатация | Резервные копии есть, восстановление реально проверено | Высокая |
| 21 | Эксплуатация | Логи фиксируют события безопасности, но не пароли, токены и лишние персональные данные | Средняя |
| 22 | Эксплуатация | Мониторинг ошибок и оповещения доходят до человека | Средняя |
| 23 | Приватность | Есть реестр персональных данных: где хранятся и какие поставщики их обрабатывают (с договорами DPA) | Высокая |
| 24 | Приватность | Пользователь может выгрузить и удалить свои данные; удаление действительно удаляет | Средняя |
Cloud Security Alliance рекомендует для любого ИИ-сгенерированного кода похожий минимум: статический анализ, проверку зависимостей и поиск секретов как обязательные шаги CI; аудит правил доступа к базе; отдельную ручную проверку кода аутентификации, API и работы с данными; SBOM; проверку того, что каждый предложенный пакет действительно существует.
Как проходит аудит-«спасение» за 3–5 дней
День 1: разрешение, доступы, инвентаризация
Сначала юридическая основа: письменное поручение и подтверждённое владение приложением, например через DNS-запись или мета-тег на домене. Затем — доступ на чтение к репозиторию, базе, хостингу и всем сторонним сервисам. Итог дня — инвентаризация: компоненты, хранилища данных, поставщики, роли пользователей и данные, к которым имеет доступ каждая роль.
День 2: автоматическое сканирование
Статический анализ кода, проверка зависимостей, поиск секретов в бандле и во всей истории git, выгрузка всех политик базы и правил хранилищ. Автоматические инструменты быстро находят очевидное — и выдают ложные срабатывания, которые должен разобрать человек.
День 3 (и 4 для крупных приложений): ручное тестирование
Обычно именно здесь находятся критические проблемы. С двумя тестовыми аккаунтами аудитор пытается через каждый эндпоинт и каждую таблицу прочитать и изменить данные другого аккаунта. Функции администратора вызываются напрямую, ИИ-эндпоинты проверяются инъекциями и большим потоком запросов.
Последний день: отчёт и критические исправления
Каждая находка получает уровень критичности, доказательство (запрос и ответ), описание последствий для бизнеса простым языком и способ исправления. Критичное — открытые таблицы, засвеченные ключи — часто исправляют в тот же день: ключи перевыпускают, тесты прогоняют повторно. Отчёт заканчивается планом исправлений и оценкой работ по остальному.
Чинить, рефакторить или переписывать?
| Что показал аудит | Решение | Типичный объём работ |
|---|---|---|
| Модель данных здоровая; проблемы — отсутствие правил, открытые ключи, незащищённые маршруты | Исправить на месте | Дни |
| Модель данных приемлема, но бизнес-логика и проверки живут в браузере | Рефакторинг: добавить полноценный серверный слой или API | Недели |
| Неверная модель данных, нет тестов, одна логика скопирована по многим экранам, глубокая привязка к платформе | Переписать ядро и перенести данные | От недель до месяцев |
Поставщики оценивают «спасательные» проекты в $50–500 тыс. на приложение, но это непроверенный диапазон из маркетинговых материалов (Creatr). Реальную стоимость определяет то, насколько придётся менять модель данных. Gartner, по пересказам, ожидает, что 75% компаний столкнутся с умеренным или высоким техническим долгом из-за ИИ-кода (Reptile.haus). Чем раньше аудит, тем дешевле исправление.
Если вы только собираетесь строить, а не чинить, структурированный спринт избавит от большинства этих проблем с самого начала — см. MVP за 14 дней.
Если вы обнаружили утечку
Открытая таблица или засвеченный ключ — это инцидент, а не пункт в списке дел:
- Локализовать: включить правила доступа, отозвать и перевыпустить ключи, отключить проблемный эндпоинт.
- Сохранить доказательства: сохранить логи, пока их ничто не перезаписало.
- Оценить: какие данные, сколько людей, как долго и был ли реальный доступ.
- Уведомить, если требуется. Для компаний, работающих в ЕС: по статье 33 GDPR об утечке персональных данных нужно сообщить надзорному органу в течение 72 часов с момента, как о ней стало известно, если она может создать риск для людей. Особенности ИИ-систем разобраны в статье о GDPR для ИИ-чат-ботов. Если ваши пользователи в других странах, сверьтесь с местным законодательством о персональных данных.
Типичные ошибки
- Прятать вместо того, чтобы защищать. Невидимая кнопка — не контроль доступа.
- Чинить только известные таблицы. Таблицы, созданные через месяц, уйдут в продакшен без RLS, если CI это не проверяет.
- Удалять ключи вместо перевыпуска. Ключ в истории git — всё ещё засвеченный ключ.
- Доверять одному сканеру. Встроенные проверки платформ полезны, но не проверяют, может ли пользователь A прочитать данные пользователя B.
- Просить тот же инструмент проверить собственную работу. ИИ-ревью помогает, но критические места должен смотреть человек, который понимает бизнес-правила.
- Тестировать без разрешения. Даже доброжелательное сканирование чужого приложения может быть незаконным.
- Считать аудит разовым мероприятием. Любая функция, сгенерированная на следующей неделе, может вернуть те же проблемы.
Вывод
Вайб-кодинг — нормальный способ быстро довести продукт до пользователей. Риски хорошо задокументированы и удивительно однообразны: правила доступа, авторизация, секреты, зависимости и ИИ-эндпоинты. Сфокусированный аудит находит критические проблемы за несколько дней, а несколько проверок в CI не дают им вернуться. Постоянный контроль после исправлений — задача сопровождения ИИ-систем (AI Ops), а не благих намерений.
Если ваше приложение уже хранит данные клиентов, стоит понимать, в каком оно состоянии. Наша команда Build проводит аудиты-«спасения» и делает последующие исправления. Запишитесь на бесплатный 15-минутный аудит — подскажем, с каких проверок начать.