Компания по кибербезопасности UpGuard обнаружила около 16 000 баз данных на платформе Supabase, доступных из интернета. Часть содержимого этих баз относилась к персональным данным: имена, адреса, телефоны, пароли пользователей. Паролей и токенов аутентификации в выборке оказалось меньше, чем остальных категорий, но даже единичные утечки такого типа дают злоумышленнику прямой доступ к аккаунтам. О находке сообщил TechCrunch со ссылкой на исследование UpGuard и комментарий Supabase.
Supabase - это бэкенд-платформа, которая даёт разработчику управляемый PostgreSQL, аутентификацию, файловое хранилище и автоматически сгенерированные API поверх базы. Отдельный API писать не нужно: таблица в Postgres сразу становится доступной по HTTP. Такой подход сильно ускоряет запуск, и именно поэтому на платформе массово селятся приложения, собранные через vibe-coding. Ранее в этом году Supabase достигла оценки в 10 млрд долларов, и рост связан в том числе с наплывом разработчиков, которые размещают на ней проекты, сгенерированные AI-инструментами.
Состав утёкших наборов данных показывает, насколько разными бывают эти проекты. В базах нашлись приватные переписки с секс-работниками на индийском взрослом стриминговом сайте, тысячи номерных знаков американского valet-сервиса, контакты пользователей иммиграционного и релокационного сервиса. Отдельно UpGuard упоминает базу консульства африканского государства во Франции и базу, которую использовали для перехвата SMS через виртуальную SIM-ферму: такие фермы применяют для приёма одноразовых кодов подтверждения, обычно в мошеннических и фишинговых схемах.
Большинство открытых наборов данных, по оценке UpGuard, физически размещены в США, но саму проблему компания называет общемировой. Публичный доступ не зависит от страны и юрисдикции: он зависит от конфигурации проекта.
Почему vibe-coding приводит к открытым базам данных
Vibe-coding строится на простой идее: вы описываете задачу словами, AI-агент генерирует код, вы деплоите результат, не читая каждую строку. Скорость получается высокой, и первое, что выкидывается из процесса, - проверка настроек доступа. В исследовании UpGuard прямо сказано: AI-инструменты позволяют легко собирать сайты и приложения, но сгенерированный код часто содержит ошибки безопасности, а приложение может требовать специфической конфигурации, о которой разработчик не знает.
Разработчик при этом видит, что приложение работает. Форма регистрации сохраняет пользователя, чат показывает сообщения, дашборд рисует статистику. Ни один из этих сигналов не говорит о том, что база закрыта от посторонних. Ошибка обнаруживается только тогда, когда кто-то посторонний её использует.
Как работает Supabase и где возникает брешь
Supabase разворачивает PostgreSQL и публикует поверх него REST- и Realtime-API. Клиент обращается к таблицам напрямую, а ключ доступа лежит в клиентском коде или в переменных окружения фронтенда, то есть его может извлечь любой, кто открыл страницу и посмотрел сетевые запросы. Публичный ключ (anon key) так и задуман: он не секрет и не даёт прав сам по себе.
Разграничение доступа делает Row Level Security, RLS, - механизм PostgreSQL, который включается отдельно для каждой таблицы и требует политик. Если для таблицы RLS не активна или активна, но с политикой вида «разрешить чтение всем», API вернёт данные в ответ на обычный запрос:
GET /rest/v1/orders?select=*
apikey: <публичный ключ проекта>
Authorization: Bearer <публичный ключ проекта>Ответ на такой запрос содержит всю таблицу. Никакого взлома, обхода защиты или подбора пароля не нужно: сервер честно отдаёт то, что разрешено политиками. Если политика разрешает ещё и запись, посторонний может добавить, изменить или удалить строки.
Типичные ошибки разработчиков при работе с Supabase
- RLS не включена для таблиц: частая ситуация, когда схему создавали SQL-скриптом или миграцией, сгенерированной AI.
- Политика «allow all»: разработчик включает RLS, но ставит разрешение на все операции для роли anon, чтобы быстро отладить интеграцию, и забывает сузить её перед деплоем.
- Сервисный ключ (service_role) в клиентском коде. Он обходит RLS полностью, и его попадание в браузерный бандл равносильно выдаче полных прав на базу.
- Отсутствие проверки прав внутри приложения: логика доступа опирается только на то, что «пользователь не должен угадать чужой URL».
- Публичные бакеты хранилища: файлы становятся доступны по прямой ссылке даже при аккуратно настроенных таблицах.
Отдельная проблема - правки, которые AI вносит позже. Агент может создать новую таблицу для фичи и не добавить к ней политики, потому что в исходной постановке задачи про безопасность речи не было. Supabase и до этого исследования сталкивалась с критикой за подход к безопасности: случаи, когда пользователи неправильно настраивали базы и открывали их в интернет, документированы широко, иногда речь шла о наборах на миллионы записей.
Какие данные утекли и чем это грозит
Категории данных различаются по последствиям, и это важно для оценки риска. Имена, адреса и телефоны сами по себе дают основу для целевого фишинга и социальной инженерии: злоумышленник знает, к кому обращается. Пароли и токены аутентификации переводят ситуацию в другую плоскость. Токены позволяют действовать от имени пользователя без пароля, а пароли, особенно переиспользованные, открывают credential stuffing по другим сервисам.
Примеры из исследования показывают, как абстрактный риск превращается в конкретный:
- Приватные переписки на взрослой стриминговой платформе - материал для шантажа и репутационного ущерба, причём пострадавшие часто не заинтересованы в публичном разбирательстве.
- Тысячи номерных знаков valet-сервиса - связка автомобиля с человеком, которая помогает отслеживать перемещения и готовить кражи.
- Контакты пользователей иммиграционного и релокационного сервиса - идеальная база для фишинга от имени сервиса: люди в процессе переезда ждут писем и охотно переходят по ссылкам.
- База консульства африканского государства во Франции - документы такого уровня затрагивают уже не только частных лиц.
- SIM-ферма для перехвата SMS - открытая база инфраструктуры, которая сама используется для мошенничества с одноразовыми кодами.
История утечек через неправильно настроенные серверы, базы и сайты длинная: в подобных инцидентах утекали служебная переписка военных, иммиграционные и визовые заявления, закрытые правительственные файлы, сотни тысяч сканов водительских прав и персональные данные детей. Механизм каждый раз один и тот же - хранилище доступно тому, кому не должно быть доступно.
Позиция Supabase: «безопасно по умолчанию» и общая ответственность
Директор по информационной безопасности Supabase Бил Хармер заявил, что компания не видела исследование UpGuard на момент комментария, но её проекты «безопасны по умолчанию». Безопасность он описал как общую ответственность компании и клиентов: «Мы предоставляем безопасные настройки по умолчанию и инструменты, а клиенты контролируют, как настроены их проекты». По его словам, компания уведомляет затронутых клиентов, когда находит проблемы. Это же утверждение приводится в материале TechCrunch.
Спор здесь не про факты, а про границы ответственности. Позиция платформы логична: RLS, политики и ключи - часть проекта клиента, и платформа не может угадать, какие данные в конкретной таблице считаются публичными, а какие нет. Со стороны разработчика картина выглядит иначе: если инструмент генерирует схему и API автоматически, разумно ожидать, что защита тоже будет выстроена по умолчанию, а не останется задачей, о которой нужно знать заранее.
Контекст усложняет оценку. Текущее исследование продолжает более ранние работы, в которых открытые базы на Supabase уже находили, включая проекты стартапов Y Combinator и других популярных приложений. Supabase со временем меняла платформу, усиливая защиту и контроль доступа к базам, но проблема воспроизводится снова.
Как защитить свой проект на Supabase: практический чек-лист
Проверка занимает меньше времени, чем разбор последствий утечки. Порядок действий для проекта на Supabase:
- Включить RLS для всех таблиц в схеме public и проверить, что ни одна таблица не осталась без флага.
- Настроить политики по принципу «запрещено всё, что не разрешено явно»: отдельные политики на чтение, вставку, обновление и удаление.
- Убрать сервисный ключ из клиентского кода. Ему место только на сервере, в бэкенд-функциях и обработчиках вебхуков.
- Хранить ключи в переменных окружения и не коммитить .env в репозиторий.
- Проверить бакеты хранилища: публичными оставлять только те, что действительно отдают файлы всем, остальные закрывать и раздавать через подписанные ссылки.
- Включить логирование и периодически смотреть, какие запросы приходят к API и от каких ролей.
- Прогнать сгенерированный код через статический анализ и просмотреть вручную места, где приложение обращается к базе напрямую.
- Свериться с документацией Supabase по безопасности перед деплоем, а не после инцидента.
Настройка RLS: пример политики для типичного приложения
Типовая задача - таблица профилей, где каждый пользователь видит только свою строку. Включение защиты и две политики выглядят так:
alter table profiles enable row level security;
create policy "read own profile"
on profiles for select
using (auth.uid() = user_id);
create policy "update own profile"
on profiles for update
using (auth.uid() = user_id)
with check (auth.uid() = user_id);Ключевая деталь - условие auth.uid() = user_id: оно привязывает строку к аутентифицированному пользователю, и запрос без токена вернёт пустой результат. Политики комбинируются: для публичного каталога товаров чтение можно открыть всем, а запись оставить только аутентифицированным с проверкой владения. Если политики не созданы, включённая RLS закрывает таблицу целиком, и это безопасное состояние по умолчанию. AI-генераторы кода такие политики почти никогда не создают, потому что в промпте речь шла о функциях, а не о правилах доступа. Живой пример того, как это выглядит на практике: в разборе пет-проекта MirrorVote код писал Claude Code, а архитектуру, RLS, идемпотентные вебхуки и логирование пришлось делать руками.
Инструменты для проверки безопасности AI-кода
Автоматизация не заменяет ревью, но отсекает часть ошибок. Практичный минимум: статический анализ JavaScript и TypeScript (ESLint с плагинами безопасности, Semgrep), проверка зависимостей на известные уязвимости (npm audit, Snyk), отдельный просмотр diff по миграциям и SQL-файлам, которые сгенерировал агент. Именно в миграциях чаще всего и появляются новые таблицы без RLS.
Ограничение у этого подхода есть: сканеры не знают вашей модели доступа. Они не скажут, что поле с номером телефона не должно отдаваться в публичном списке. Такие вещи ловит только ручная проверка сценариев доступа. Полезно помнить и о скорости: AI-инструменты ускоряют поиск уязвимостей не хуже, чем генерацию кода, и это видно по сообщениям об исследованиях вроде поиска уязвимостей в инфраструктуре OpenAI. Разбор того, как выстроить конвейер сканеров без горы ложных срабатываний, есть в материале про DevSecOps для AI-разработки.
Что это значит для будущего vibe-coding
Инцидент с 16 000 баз не отменяет vibe-coding. Он показывает его слабое место: AI отлично генерирует функциональность и плохо - защиту по умолчанию. Пока инструмент оптимизирован под то, чтобы приложение работало, а не под то, чтобы оно было закрыто, аудит доступа остаётся задачей разработчика.
Отсюда несколько практических выводов. Первый: безопасность стоит встроить в процесс, а не в конец. Промпт вида «создай таблицу с RLS и политиками для владельца строки» дешевле, чем разбирательство после утечки. Второй: платформы могут усиливать настройки по умолчанию, но полностью переложить на них ответственность не получится, потому что модель доступа знает только автор проекта. Третий: проблема не уникальна для Supabase - неправильно настроенные серверы и базы данных утекают десятилетиями, меняются только инструменты и скорость появления новых приложений.
Тот же урок виден в историях вокруг автономных агентов и их полномочий: когда система получает лишние права и лишний сетевой доступ, локальная ошибка превращается в системный риск. Разбор похожего сюжета с агентом OpenAI есть в статье про инцидент с Hugging Face и культурой безопасности. Применительно к базам вывод простой: перед деплоем откройте список таблиц, проверьте, что RLS включена и политики описывают только нужные операции, а сервисный ключ не уехал в браузер. Эта проверка займёт десять минут и снимет риск, который уже реализовался в десятках тысяч чужих проектов.