Утечки данных в vibe-coded приложениях: как AI-конструкторы открывают внутренние сервисы

По состоянию на 7 мая 2026 года утечки данных в vibe-coded приложениях перестали быть редким курьёзом из X и Reddit. WIRED и Axios почти одновременно описали находки компании RedAccess: внутренние инструменты, клинические данные, финансовые документы, логи клиентских чатов и другие чувствительные данные оказывались в публично доступных веб-приложениях, собранных через Lovable, Replit, Base44 и связанные контуры публикации.

Самое важное в этой истории не то, что ИИ «пишет плохой код». Во многих случаях проблема грубее: приложение получает публичный URL, индексируется поисковиками, а защита либо отсутствует, либо сводится к формальной аутентификации. Когда внутренний инструмент публикует человек без security-бэкграунда, утечка начинается раньше, чем кто-то успевает обсуждать качество сгенерированного JavaScript.

Что именно нашли WIRED и Axios

Здесь легко запутаться в цифрах, потому что WIRED и Axios пересказывают RedAccess на двух разных уровнях. Это не обязательно противоречие, но это точно тот случай, где нельзя писать таблицу «по памяти».

Практический вывод отсюда простой: эти цифры нельзя складывать лоб в лоб, но их и нельзя списать на журналистскую путаницу. Axios говорит о большом массиве публичных объектов. WIRED — о подмножестве приложений, где защита отсутствовала или сводилась к формальности. В обоих случаях результат один и тот же: внутренние и персональные данные уходят в открытый веб быстрее, чем компании успевают заметить сам факт публикации.

Axios приводит особенно наглядные примеры: приложение для shipping-компании с деталями по судам и портам, внутренний инструмент health-компании по активным clinical trials в Великобритании, финансовую информацию бразильского банка, разговоры пациентов в long-term care facility, hospital app с doctor and patient conversation summaries, а также school app с lesson recordings и student-related data. Это уже не рассказ о том, что «кто-то выложил тестовый TODO-app».

Как утечки вообще выходят в открытый веб

Ключевой момент у WIRED звучит почти буднично: Lovable, Replit, Base44 и Netlify позволяют размещать приложения на своих доменах, а не только на домене клиента. RedAccess искала такие приложения обычными запросами в Google и Bing по доменам платформ. То есть путь к экспозиции в ряде случаев не требует ни взлома, ни редкой уязвимости. Достаточно того, что приложение уже опубликовано на публичном URL и содержит данные, которые не должны были туда попасть.

Axios добавляет ещё один неприятный слой. По словам исследователей, на части платформ privacy settings были настроены так, что приложение оказывалось публично доступным, если пользователь вручную не переводил его в private-режим. Даже когда формально речь идёт о «публикации по ссылке», на практике это уже открытый веб: страницу может увидеть поисковик, индексатор, внешний сканер или человек, который просто перебирает домены.

Дальше начинается самое интересное, потому что официальная документация самих платформ подтверждает: публичная публикация здесь не экзотическая аварийная ветка, а нормальный продуктовый сценарий.

• Lovable прямо пишет, что на Free и Pro планах опубликованное приложение может открыть любой, у кого есть ссылка, а ограничить website access на этих планах нельзя.
• Replit описывает публикацию как выбор между Public, Workspace only и Only you. Это уже лучше, чем жёсткий public-only сценарий, но публичный режим всё равно встроен в основной workflow публикации.
• Base44 пишет, что smart app visibility может автоматически предложить Public для приложений, которые похожи на лендинги или публичные сайты. При этом login и более жёсткие режимы нужно включать отдельно.

Именно здесь проблема безопасности перестаёт быть абстракцией. Если продукт делает публикацию слишком дешёвым и естественным действием, а пользователь строит внутренний инструмент «на скорую руку», то ошибка уже не выглядит как ошибка. Она выглядит как нормальный следующий шаг в интерфейсе.

Почему это не только история про плохой код

У Lovable есть ещё одна важная формулировка, которую полезно читать не как документацию, а как предупреждение. Компания пишет, что клиентский слой в приложениях всегда публичен и ему нельзя доверять, а секреты, оставленные в коде интерфейса, видимы пользователям и должны считаться скомпрометированными. Любая логика, которая влияет на безопасность, аутентификацию, целостность данных и внешние API, должна жить на серверной стороне.

Это важно, потому что массовая утечка в vibe-coded приложениях часто начинается не с «хакер нашёл хитрую дыру», а с более приземлённой цепочки:

1. внутренний инструмент быстро собирают через AI-конструктор;
2. данные и логика остаются слишком близко к клиентскому слою;
3. приложение публикуют на внешнем URL;
4. auth не настроен или настроен символически;
5. поисковик, внешний пользователь или бот просто открывает уже опубликованную страницу.

Эта цепочка хорошо рифмуется с другим свежим исследованием, уже не про vibe coding, а про веб вообще. В марте 2026 года работа Keys on Doormats: Exposed API Credentials on the Web описала сканирование 10 миллионов веб-страниц и нашла 1 748 distinct credentials от 14 провайдеров почти на 10 000 страницах. Авторы отдельно пишут, что многие такие экспозиции происходят в JavaScript-окружениях. Иными словами, проблема «секреты и доступы утекли в публичный веб-контур» существовала и до бума AI-конструкторов. Vibe coding просто ускоряет и масштабирует этот паттерн.

Поэтому честный вывод звучит не как «инструменты AI-кодинга опасны сами по себе», а как «порог публикации стал слишком низким относительно порога проверки безопасности». Раньше у компании хотя бы было трение: нужен разработчик, нужен деплой, нужен человек, который понимает аутентификацию, маршруты и данные. Теперь внутреннее приложение может собрать аналитик, операционный менеджер или фаундер, который вчера вообще не открывал IDE.

Что отвечают сами платформы

Важно не превращать эту историю в односторонний обвинительный акт. По WIRED, Replit, Lovable и Base44 спорили с полнотой отчёта и временем на реакцию. Replit CEO Amjad Masad написал, что public apps being accessible on the internet — expected behavior, а privacy settings можно поменять в один клик. Axios также цитирует Lovable: компания воспринимает сообщения о data exposure и phishing seriously, но просила URL и технические детали, чтобы можно было расследовать случаи по существу.

Это нормальная позиция для платформы. Проблема в другом: фактическая логика продукта здесь всё равно остаётся прежней. Если режим публичной публикации встроен в обычный пользовательский путь, если на части планов доступ к приватному URL ограничен, а security check остаётся рекомендацией, то вся система очень сильно рассчитывает на дисциплину конечного пользователя. А ровно её-то в сценарии теневого использования ИИ обычно и не хватает.

Именно поэтому история не заканчивается фразой «пользователь сам нажал Publish». Да, нажал. Но рынок одновременно продвигает мысль, что строить и выкатывать софт теперь можно почти без инженерной подготовки. Если так, то вопрос про безопасные настройки по умолчанию, индексируемость в поиске и обязательные проверки безопасности перестаёт быть второстепенной деталью интерфейса. Он становится частью самого продукта.

Что делать компаниям прямо сейчас

Ниже — не юридическая политика и не vendor blame game, а наш практический вывод из источников выше.

• Проведите инвентаризацию внутренних приложений, которые опубликованы на доменах вроде *.lovable.app, *.replit.app и похожих внешних хостинговых контурах. Исходите из того, что теневое использование ИИ уже существует, даже если у вас нет формальной программы вокруг него.
• Для внутренних инструментов запретите публичную публикацию там, где платформа это позволяет, и включите настройки workspace/private по умолчанию на уровне организации, а не на уровне личной привычки автора.
• Проверьте, не уехали ли аутентификация, проверки ролей, валидация и вызовы внешних API в клиентский слой. Если да, это уже не просто «быстрый MVP», а прямой кандидат на утечку.
• Ищите secrets и токены в публичном веб-контуре, а не только в GitHub. Исследование Stanford показывает, что exposed credentials живут на страницах месяцами и даже годами.
• Разведите демо-данные, боевые данные и персональные данные. Медицинские сводки, клиентские чаты, графики сотрудников и внутренние финансовые отчёты не должны быть топливом для быстрого цикла по созданию внутренних тулов.
• Сделайте проверку безопасности обязательным этапом перед публикацией. Если платформа предлагает security check, access controls и private mode, это должно быть не «желательно», а «без этого релиза нет».

Если смотреть шире, этот сюжет хорошо стыкуется с нашими соседними материалами. В разборе рисков AI-интеграций на примере Vercel и Context.ai проблема начиналась с OAuth и внешнего инструмента, который получил слишком широкий доступ. В материале про OpenAI Privacy Filter мы разбирали другой слой защиты: как вообще не тащить персональные данные и секреты дальше по AI-пайплайну. А история про Apple и вайб-кодинг показывает уже рыночную реакцию платформ: как только сгенерированные приложения выходят наружу, импровизация очень быстро заканчивается.

Итог

Утечки данных в vibe-coded приложениях — это не спор о том, умеет ли LLM писать хороший код. Это спор о том, насколько быстро рынок научился публиковать софт и насколько медленно он научился контролировать, кто может открыть URL, где живёт аутентификация и какие данные попали в приложение. В 2026 году первый большой риск AI-конструкторов — не изящная zero-day уязвимость, а банальная публикация внутреннего инструмента в публичный веб-контур.

Поэтому правильный вопрос для любой команды теперь звучит так: кто может открыть app URL, индексируется ли он, где проходят проверки доступа, какие данные в нём живут и кто дал добро на publish. Если на любой из этих вопросов нет чёткого ответа, вы смотрите не на «ускорение разработки», а на будущий инцидент.

Читайте также

• Риски AI-интеграций: урок Vercel и Context.ai
• OpenAI Privacy Filter: маскировка PII локально
• Вайб-кодинг App Store: почему Apple фильтрует AI

Источники

• WIRED: Thousands of Vibe-Coded Apps Expose Corporate and Personal Data on the Open Web, опубликовано 7 мая 2026 года, проверено 7 мая 2026 года.
• Axios: AI vibe-coding apps leak sensitive data, опубликовано 7 мая 2026 года, проверено 7 мая 2026 года.
• Lovable Docs: Publish your app, проверено 7 мая 2026 года.
• Lovable Docs: Security best practices for Lovable apps, проверено 7 мая 2026 года.
• Replit Docs: Private deployments, проверено 7 мая 2026 года.
• Base44 Docs: Choosing who can access your app, проверено 7 мая 2026 года.
• arXiv: Keys on Doormats: Exposed API Credentials on the Web, версия от марта 2026 года, проверено 7 мая 2026 года.