Как защитить приложение, сделанное вайб-кодингом, прежде чем им поделиться
Коротко
Прежде чем коллеги начнут пользоваться приложением, которое вы сделали с ИИ, проверьте четыре вещи: никто не проходит дальше входа через аккаунт компании, войти могут только аккаунты вашей компании, в коде, который работает в браузере, нет ключей, а базу данных нельзя прочитать в обход приложения. Затем проверьте, кто что может делать внутри приложения и кто станет его владельцем, если вы уйдёте.
Большинство утечек из приложений, сделанных с ИИ, это не хитрые атаки. Это открытые двери: публичная ссылка, база данных с выключенными правилами, ключ прямо на странице. Этот чек-лист для того, кто сделал приложение, и для сотрудника ИТ, который его проверяет. В каждом пункте сказано, что может пойти не так, как проверить это простыми словами, что берёт на себя TeamOnly и что остаётся на вас.
Обновлено Написано TeamOnly. Мы размещаем внутренние приложения, сделанные с ИИ, и в каждом пункте честно говорим, где помогаем, а где нет.
01Почему это важно
Что идёт не так с приложениями, сделанными с ИИ
ИИ-инструменты хорошо умеют сделать так, чтобы приложение работало. Гораздо меньше они следят за тем, для кого ещё оно работает. Три находки за последние два года показывают закономерность.
380 000
общедоступных ресурсов на Lovable, Base44, Netlify и Replit нашла компания Red Access, которая занимается безопасностью, в мае 2026 года. Около 5 000 из них содержали конфиденциальные данные компаний, и многие были проиндексированы Google.
170 из 1 645
приложений Lovable, проверенных в марте 2025 года, позволяли любому читать или менять данные в их базе Supabase без входа, потому что правил доступа к базе не было или они были неверными (CVE-2025-48757).
205 474
выдуманных названия пакетов предложили 16 ИИ-моделей в 576 000 примерах кода, по данным исследования 2025 года. Злоумышленники могут опубликовать пакеты под этими названиями и ждать, пока кто-нибудь их установит.
Ни в одном случае не понадобился хитрый злоумышленник. Двери были открыты. И это хорошая новость: открытые двери легко проверить, и для этого не нужно читать код.
Проходите их по порядку. Первые не пускают посторонних, следующие ловят ошибки внутри компании.
До входа через аккаунт компании ничего не загружается
Что идёт не так
ИИ-инструменты часто делают экран входа одной из страниц приложения. Остальное приложение и его API всё равно отвечают любому, кто пропустит эту страницу или обратится к API напрямую. Red Access находила приложения компаний, которые давали права администратора любому, кто открыл адрес.
Проверьте сами
Откройте приложение в приватном окне браузера. Вы должны увидеть экран входа и больше ничего. Затем спросите ИИ-инструмент: «Перечисли все маршруты API и скажи, какие из них работают без входа». Правильный ответ: никакие.
На TeamOnly
Решено. Каждый запрос к каждому приложению проверяется до того, как запустится хоть строчка вашего кода, включая вызовы API, которые без сессии получают 401. Настройки, которая делает приложение публичным, нет.
Входят только аккаунты вашей компании
Что идёт не так
«Войти через Google» по умолчанию пускает любой аккаунт Google, включая личный Gmail. Параметр Google hd только сужает список аккаунтов при выборе, и Google предупреждает, что на него нельзя полагаться, потому что запрос можно подменить. Домен нужно проверять на сервере.
Проверьте сами
Попробуйте войти с личным аккаунтом Gmail или Outlook. Вам должны отказать. Спросите ИИ-инструмент, где сервер проверяет домен почты и проверяет ли он подписанный токен от Google или значение, которое прислал браузер.
На TeamOnly
Решено. Коллеги входят через рабочий Google, рабочий Microsoft или по коду, отправленному на рабочую почту. Домен в проверенном токене входа сверяется с доменами вашей компании, а личные аккаунты получают отказ.
Внутри компании только нужные люди
Что идёт не так
Приложение с зарплатами, отзывами о работе или данными клиентов открывают всей компании, потому что так было по умолчанию. Или ИИ пишет в коде свой список разрешённых, который никто не обновляет.
Проверьте сами
Спросите себя: должны ли все в компании видеть эти данные? Если нет, запишите имена тех, кому можно, и проверьте, что человек не из этого списка получает отказ.
На TeamOnly
Решено, выбираете вы. Доступ есть у всей компании или у списка конкретных людей, это задаётся в панели управления или командой npx teamonly access only priya@acme.com. Проверка идёт при каждом запросе, поэтому удаление человека срабатывает в течение минуты.
Не по публичной ссылке и не в результатах поиска
Что идёт не так
Некоторые конструкторы приложений публикуют по публичному адресу, если вы не выбрали закрытый доступ. Публичные приложения находят: Red Access сообщила, что многие открытые приложения компаний были проиндексированы Google и другими поисковиками.
Проверьте сами
Найдите в Google site: с адресом вашего приложения. Проверьте настройку видимости проекта на платформе, где вы его делали. Если там написано «публичный», первым делом измените это.
На TeamOnly
Решено. Приложения живут по адресу yourapp.yourcompany.teamonly.app за экраном входа. Каждый ответ, включая экран входа, запрещает поисковикам индексацию, а на экране входа видно только название приложения и способы войти.
В коде, который работает в браузере, нет ключей
Что идёт не так
ИИ-инструменты кладут API-ключи в код на React или в переменные, начинающиеся с VITE_ или NEXT_PUBLIC_. Всё, что отправлено в браузер, может прочитать любой, кто открыл приложение. Supabase говорит, что его секретный ключ никогда не должен попадать в браузер, потому что он обходит все правила базы данных.
Проверьте сами
Спросите ИИ-инструмент: «Есть ли какой-нибудь ключ, токен или пароль в коде фронтенда, в переменной VITE_ или в закоммиченном файле .env?» В браузере откройте инструменты разработчика и поищите в загруженных файлах key, secret и sk_. Если ключ когда-либо был раскрыт, смените его в сервисе, который его выдал.
На TeamOnly
Решено частично. Ключи сохраняются командой npx teamonly secrets set NAME отдельно от кода, и читать их может только серверный код вашего приложения. Инструкции, которые добавляет TeamOnly, велят ИИ-инструменту никогда не использовать ключи VITE_. Но ничто не мешает вам самим вставить ключ в код, так что всё равно проверьте.
Базу данных нельзя прочитать в обход приложения
Что идёт не так
В Supabase и похожих сервисах браузер обращается к базе данных напрямую, а что ему видно, решают правила доступа (row-level security). Когда эти правила выключены или неверны, любой с публичным ключом может читать или менять целые таблицы. Именно это и нашли в Lovable.
Проверьте сами
В Supabase откройте Advisors, затем Security Advisor. Любая ошибка «RLS disabled in public» означает таблицу, которую может прочитать кто угодно. Одного наличия правила мало: войдите как обычный коллега и попробуйте открыть чужую запись.
На TeamOnly
Решено для посторонних. У базы данных каждого приложения нет своего адреса в интернете. До неё можно добраться только через серверный код вашего приложения, после входа. Какие строки может видеть каждый вошедший, по-прежнему должен правильно решать код приложения (см. проверку 8).
Данные каждого приложения хранятся отдельно
Что идёт не так
Несколько приложений делят одну базу данных или одно хранилище, потому что так быстрее. Тогда ключ или ошибка в одном приложении открывает их все.
Проверьте сами
Спросите себя: использует ли другое приложение ту же базу данных, хранилище или ключи, что и это? Если да, то насколько безопасны все они, решает самое слабое.
На TeamOnly
Решено. При первой публикации каждое приложение получает свою базу данных, хранилище файлов и секреты, а его сессионная cookie привязана к его собственному адресу. Приложения не могут добраться до данных друг друга.
Кто что может делать, проверяется на сервере
Что идёт не так
ИИ прячет кнопку «Согласовать» от большинства людей, но оставляет маршрут согласования открытым для любого вошедшего. Или сервер доверяет роли или почте, которые присылает браузер. Нарушение контроля доступа стоит на первом месте в OWASP Top 10. Его близкий родственник это непроверенный ввод: отрицательная сумма, SQL-запрос, собранный из текстового поля.
Проверьте сами
Войдите как обычный коллега и попробуйте сделать то, что можно только руководителям. Спросите ИИ-инструмент: «Для каждого маршрута API: кто может его вызывать и где на сервере это проверяется? Все ли запросы к базе данных используют плейсхолдеры?»
На TeamOnly
Решено частично. Ваше приложение получает проверенного человека (ctx.user) и роли, которые вы выдаёте в панели управления (ctx.user.roles), а поддельные заголовки с личностью удаляются. Инструкции велят ИИ-инструменту использовать плейсхолдеры в запросах и проверять ввод на сервере. Проверка роли в каждом маршруте это код вашего приложения. TeamOnly его не проверяет.
Каждый пакет настоящий и нужен
Что идёт не так
ИИ-инструменты иногда предлагают пакеты, которых не существует. Злоумышленники публикуют пакеты под этими названиями, и установка такого пакета запускает чужой код внутри вашего приложения.
Проверьте сами
Откройте package.json. Каждое незнакомое название найдите на npmjs.com: у настоящего пакета есть история, ссылка на репозиторий с исходным кодом и стабильные загрузки. Перед публикацией запустите npm audit и удалите пакеты, которыми приложение больше не пользуется.
На TeamOnly
Не решено. TeamOnly не сканирует пакеты. Приложение может добраться только до своих данных и ключей, и это ограничивает, чего может коснуться плохой пакет, но внутри этого приложения он всё равно может прочитать всё.
Запись о том, кто что изменил
Что идёт не так
Что-то согласовали, удалили или изменили, и никто не может сказать, кто это сделал. Приложения, сделанные с ИИ, редко ведут историю, если об этом не попросить.
Проверьте сами
Попросите ИИ-инструмент записывать, кто создал и кто последним изменил каждую запись и когда, и вести таблицу истории для согласований и удалений. Проверьте: измените запись и найдите на ней своё имя.
На TeamOnly
Решено частично. Панель управления показывает каждую публикацию каждого приложения, кто и когда опубликовал, и логи в реальном времени. Логи идут в реальном времени и не хранятся. Журнал аудита входов и изменений доступа есть на тарифе Business, настроим вместе с вами. История внутри приложения (кто согласовал расход) это задача вашего приложения.
Владелец, резервная копия и план на случай ухода
Что идёт не так
Автор уходит, а приложение продолжает работать на его личном аккаунте или останавливается, когда его карту отменяют. Или неудачное изменение стирает таблицу, а копии нет.
Проверьте сами
Запишите, кто владелец приложения и кто его заменит. Храните код в Git-репозитории компании. Попросите ИИ-инструмент добавить экспорт основных таблиц в CSV и проверьте его.
На TeamOnly
Решено частично. Приложения принадлежат вашей компании, и администраторы могут передать приложение новому владельцу. Отключение рабочего аккаунта человека останавливает новые входы. Те, кто уже вошёл, остаются внутри до конца сессии, а её длительность выбирают администраторы, от 8 часов до 30 дней. Кнопки резервной копии или экспорта в панели управления сейчас нет, поэтому встройте экспорт в само приложение.
03Распечатайте
Проверка за одну минуту
Одиннадцать вопросов с ответом «да» или «нет». Каждое «нет» это следующее, что нужно исправить.
Прежде чем делиться этим приложением
В приватном окне браузера виден вход через аккаунт компании и больше ничего.
Личный аккаунт Gmail или Outlook получает отказ.
Открыть приложение могут только те, кому нужны эти данные.
Поиск site: по адресу приложения ничего не находит.
В коде для браузера и в репозитории нет ни ключей, ни токенов, ни паролей.
До базы данных нельзя добраться в обход приложения.
Данные и ключи этого приложения не общие ни с каким другим приложением.
Обычный коллега не может сделать то, что можно только руководителям.
Каждый пакет в package.json настоящий и до сих пор используется.
В записях видно, кто их создал и изменил.
Кто-то другой знает, что станет владельцем приложения, если я уйду, а данные можно выгрузить.
Пятнадцать минут с автором, с демонстрацией экрана. Вы проверяете настройку, а не читаете каждую строку кода.
Где оно живёт и кто может до него добраться
Узнайте адрес. Откройте его с устройства, где не выполнен вход, и с личного аккаунта. Спросите, на какой платформе оно размещено и чей аккаунт за него платит. Личный аккаунт это первое, что нужно поменять.
Какие данные в нём хранятся
Спросите, что туда попадает и откуда. Персональные данные клиентов, платёжные данные, медицинские данные или пароли от других систем поднимают планку и могут означать, что доступ к приложению стоит ограничить списком конкретных людей.
Где лежат ключи
Перечислите все внешние сервисы, к которым обращается приложение. Каждый ключ должен храниться в настройках секретов хостинга, иметь только нужные приложению права и не быть общим с другими приложениями. Смените каждый ключ, который когда-либо был в коде или в чате.
Кто что может делать
Попросите автора войти как обычный пользователь или попросите об этом коллегу и попробуйте действия администратора. Попросите автора, чтобы его ИИ-инструмент перечислил все маршруты API и места, где проверяется роль. Пробелы здесь исправляются в коде приложения.
Пакеты и код
Вместе посмотрите package.json и запустите npm audit. Попросите, чтобы код хранился в Git-репозитории компании, а не только на ноутбуке автора.
Владелец и день, когда он уйдёт
Запишите в свой список приложений само приложение, его владельца, запасного владельца, данные и пользователей. Договоритесь, что будет, когда владелец уйдёт. В руководстве по теневым ИИ-приложениям есть политика на одну страницу, которую можно скопировать.
Безопасно ли делиться с коллегами приложениями, сделанными вайб-кодингом?
Может быть безопасно. Обычные проблемы связаны с тем, где приложение размещено и как оно настроено: публичная ссылка, нет настоящего входа, ключи в браузере, выключенные правила базы данных. Каждую можно проверить за несколько минут. Пройдите чек-лист на этой странице, прежде чем отправлять ссылку.
Какой главный риск безопасности у приложения, сделанного вайб-кодингом?
Данные, до которых любой может добраться без входа. Обычно это случается одним из двух способов: приложение висит по публичной ссылке без входа, или база данных отвечает на запросы напрямую, а её правила доступа выключены (row-level security в Supabase). В обоих случаях дело в настройке, а не в том, что ИИ написал плохой код.
Можно ли держать anon-ключ Supabase в браузере?
Ключ anon, или publishable, сделан для браузера, но только потому, что row-level security ограничивает, до чего он может добраться. Если на таблице row-level security выключена, любой с этим ключом может читать и менять её. Ключ secret или service_role никогда не должен попадать в браузер: он обходит все правила.
Ограничивает ли «Войти через Google» приложение моей компанией?
Само по себе нет. По умолчанию войти может любой аккаунт Google, включая личный Gmail. Параметр Google hd только сужает список аккаунтов при выборе, и Google советует на него не полагаться. Сервер приложения должен при каждом запросе проверять домен в проверенном токене входа.
Как проверить, проиндексировал ли Google моё приложение?
Найдите в Google site: с адресом вашего приложения, например site:myapp.lovable.app. Если появились страницы, приложение публичное и проиндексировано. Сделайте приложение закрытым или перенесите его за вход через аккаунт компании, а затем, если домен ваш, попросите Google удалить страницы через инструмент «Удаления» в Search Console.
Стоит ли просить ИИ-инструмент писать безопасный код?
Да, и лучше дать ему постоянные инструкции, чем попросить один раз. Файл правил в проекте (CLAUDE.md, AGENTS.md или правило Cursor) объясняет инструменту, где хранить ключи, как писать запросы к базе данных и где проверять роли. Для приложений TeamOnly их добавляет npx teamonly init. И всё равно проведите проверки сами: инструкции уменьшают число ошибок, но не убирают их.
Сканирует ли TeamOnly код моего приложения на проблемы безопасности?
Нет. TeamOnly ставит вход через аккаунт компании перед каждым приложением, держит данные и ключи каждого приложения отдельно и не пускает приложения в поисковики. Он не проверяет ваш код, не сканирует пакеты и не проверяет правила внутри приложения. Эти пункты чек-листа остаются на вас.
Что ИТ стоит проверить, прежде чем одобрить приложение, сделанное с ИИ?
Где оно размещено и кто может до него добраться, как ограничен вход, где лежат ключи, какие данные в нём хранятся, кто его владелец и что будет, когда этот человек уйдёт. Раздел «Для ИТ» на этой странице это короткая проверка, которую можно провести вместе с автором за 15 минут.
Опубликуйте приложение одной командой, и оно окажется за входом через аккаунт компании, вне поиска, со своей базой данных и секретами. Попробуйте 14 дней бесплатно, без карты.