Открытые базы Supabase снова стали неприятным напоминанием: AI-сборка приложения не отменяет базовую безопасность. Исследователи UpGuard нашли около 16 тысяч баз данных на платформе Supabase, где в публичный доступ попадали персональные данные, сообщает TechCrunch. Для разработчиков, стартапов и IT-директоров это не экзотическая история про чужую небрежность, а вполне рабочий риск: сервисы на Supabase часто поднимают быстро, а проверяют права доступа уже когда что-то горит.
По данным UpGuard, в найденных базах встречались имена, адреса, номера телефонов и пароли пользователей. Паролей и authentication-токенов было меньше, чем обычной контактной информации, но сам факт их наличия резко повышает цену ошибки. Речь не о взломе Supabase как инфраструктуры, а о проектах клиентов, которые оказались настроены так, что данные можно было получить из открытого веба.
Список примеров выглядит как подборка для внутреннего тренинга по тому, почему staging и production нельзя оставлять на авось. UpGuard обнаружила данные частных переписок с секс-работниками на индийском adult-стриминговом сайте, тысячи автомобильных номеров клиентов американского valet-сервиса, контакты пользователей сервиса иммиграции и релокации. Среди найденных проектов была база, связанная с консульством африканского государства во Франции. Еще один проект использовался виртуальной SIM-фермой для перехвата SMS с одноразовыми кодами, которые обычно применяют для регистрации аккаунтов, мошенничества и фишинга.
Большая часть найденных наборов данных, по оценке UpGuard, относилась к США, но исследователи отдельно подчеркивают: проблема глобальная. Это важная деталь для русскоязычной аудитории. Supabase давно используют не только американские стартапы, а все, кто хочет быстро получить Postgres, auth, storage и API без сборки инфраструктуры с нуля. В такой модели команда выигрывает время, но получает новый класс ошибок: публичные таблицы, слишком широкие политики доступа, небрежно выданные ключи, тестовые проекты, которые внезапно стали настоящим продуктом.
Контекст делает историю болезненнее. Supabase выросла на волне популярности AI-инструментов и vibe coding — подхода, когда приложение собирают быстрыми итерациями с помощью генеративных помощников, часто без полноценного инженерного цикла. Ранее в этом году оценка Supabase достигла 10 млрд долларов, и платформа стала одним из заметных бенефициаров этого бума. Чем больше людей запускают приложения без глубокого понимания backend-безопасности, тем чаще база данных превращается из хранилища в витрину.
Проблема не новая: плохо настроенные storage-бакеты, базы данных и веб-серверы годами приводили к утечкам военных писем, миграционных документов, правительственных файлов, сканов водительских удостоверений и данных детей. Новая часть сюжета — скорость. AI помогает быстрее собрать интерфейс, CRUD, форму регистрации и админку, но не гарантирует корректные Row Level Security-политики, безопасную работу с токенами и понятную модель доступа. Код может выглядеть рабочим, демо может проходить идеально, а база тем временем тихо отвечает всем желающим.
Supabase в комментарии отвергает идею, что речь идет о небезопасной платформе по умолчанию. Директор по информационной безопасности компании Бил Хармер сказал, что проекты Supabase «secure by default», а безопасность — зона общей ответственности компании и клиентов. По его словам, Supabase дает безопасные настройки и инструменты, а клиенты контролируют конфигурацию собственных проектов; если компания узнает о проблемах, она уведомляет затронутых пользователей.
Формально это стандартная и во многом справедливая позиция для облачной платформы. Практически она оставляет бизнесу простой вопрос: кто именно в команде отвечает за то, что база не торчит наружу? В маленьком AI-стартапе этим человеком может оказаться фаундер, который вчера попросил ассистента сгенерировать приложение для проверки гипотезы. В корпоративной команде — продуктовый инженер, который подключил Supabase для быстрого прототипа, а потом прототип незаметно попал к реальным пользователям.
Для разработчиков вывод неприятный, зато конкретный: открытые базы Supabase надо искать у себя до того, как их найдут исследователи или злоумышленники. Минимальный набор проверок выглядит скучно, но именно он спасает: включенные и протестированные политики RLS, ревизия публичных таблиц и storage-бакетов, запрет хранения паролей в явном виде, ротация ключей, аудит service role key, отдельные окружения для теста и продакшена, логирование подозрительных запросов. AI может ускорить разработку, но он не становится владельцем инцидента после утечки.
История UpGuard — не приговор Supabase и не повод откатываться к самописной инфраструктуре ради чувства контроля. Это сигнал, что рынок вошел в фазу, где скорость создания софта опережает культуру его эксплуатации. Следующая большая конкуренция среди backend-платформ будет не только за удобные SDK и красивые dashboards, но и за способность защитить пользователей от их собственных быстрых решений — особенно когда эти решения сгенерировал уверенный ассистент и никто не спросил, кто закрыл дверь.