Tech Review 
Введение
Supabase — популярная open-source альтернатива Firebase, построенная поверх PostgreSQL. Платформа предоставляет разработчикам базу данных, аутентификацию, хранилище файлов и API «из коробки», что делает её привлекательной для быстрого запуска MVP и продакшн-приложений. Однако за удобство приходится платить: если разработчик неправильно настраивает политики безопасности на уровне строк (Row Level Security, RLS), данные становятся доступны любому, кто знает URL проекта и публичный anon-ключ.
Именно это и произошло: исследователи в области безопасности и журналисты обнаружили, что целый ряд клиентов Supabase публично выставил в интернет массивы персональных данных — от email-адресов и телефонов до внутренней документации и токенов доступа.
Детали
Проблема связана с архитектурой Supabase. Каждый проект получает публичный API-эндпоинт и анонимный ключ (`anon key`), который по замыслу безопасен для использования на клиенте — при условии, что включена и корректно настроена RLS. RLS позволяет описать правила доступа к каждой строке таблицы: например, «пользователь видит только свои записи».
Если RLS не включена вовсе или политики написаны слишком широко (например, `SELECT` разрешён для роли `anon`), любой человек может обратиться к REST-эндпоинту Supabase и выгрузить содержимое таблиц. Инструменты вроде PostgREST, лежащего в основе API Supabase, делают это тривиальным: достаточно выполнить GET-запрос к `/rest/v1/имя_таблицы` с публичным ключом.
По сообщениям исследователей, среди утёкших данных встречались:
- таблицы пользователей с email, телефонами и хешами паролей;
- заказы и платёжные метаданные;
- внутренние заметки и тикеты поддержки;
- API-ключи сторонних сервисов, хранившиеся в открытых таблицах.
Масштаб варьируется от проекта к проекту: где-то это сотни записей, где-то — сотни тысяч. Точное число пострадавших организаций и пользователей не раскрывается, поскольку инциденты носят распределённый характер: это не одна утечка в Supabase, а множество независимых ошибок конфигурации у клиентов платформы.
Supabase со своей стороны неоднократно подчёркивала, что RLS — это ответственность разработчика, и предоставляет документацию, предупреждения в панели управления и инструменты для аудита. Тем не менее, по умолчанию RLS для новых таблиц не всегда включена, что и становится ловушкой для неопытных команд.
Анализ
Ситуация показательна для всего класса BaaS-платформ (Backend-as-a-Service). Firebase, Supabase, Appwrite и аналогичные решения сознательно снижают порог входа: разработчик получает работающий бэкенд за минуты. Но безопасность в таких системах строится на декларативных правилах, которые легко забыть или настроить неверно.
Ключевая проблема — асимметрия последствий. Ошибка в конфигурации RLS не ломает приложение: всё продолжает работать, пользователи логинятся, данные отображаются. Никакого сигнала тревоги не поступает. При этом база фактически открыта наружу. В традиционной архитектуре с собственным бэкендом разработчик должен явно написать эндпоинт и обработчик — и хотя бы задуматься об авторизации. В Supabase публичный доступ — это состояние по умолчанию, которое нужно явно закрыть.
Дополнительный фактор — популярность вайб-кодинга и генерации приложений с помощью ИИ. LLM-ассистенты охотно пишут код для Supabase, но далеко не всегда добавляют миграции с `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` и политиками. В результате появляется целый пласт приложений, собранных быстро и без ревью безопасности.
Стоит отметить и роль самого вендора. Supabase могла бы сделать RLS включённой по умолчанию для всех новых таблиц, а также добавить более агрессивные предупреждения и автоматическое сканирование проектов на открытые таблицы. Часть этих мер уже реализована (например, индикаторы в дашборде и линтер безопасности), но, судя по продолжающимся находкам, их недостаточно.
Мнение
Supabase — не «дырявый» продукт. Это мощный и хорошо спроектированный инструмент, который, как и любой инструмент, требует понимания модели безопасности. Обвинять платформу в том, что разработчики не читают документацию, было бы несправедливо. Но и снимать с вендора ответственность нельзя: когда типовой сценарий использования массово приводит к утечкам, это уже не только проблема пользователей.
На мой взгляд, индустрии нужен сдвиг в сторону «безопасных по умолчанию» настроек. RLS должна быть включена всегда, а её отключение — осознанным действием с явным подтверждением. Аналогично тому, как современные браузеры блокируют смешанный контент, а облачные провайдеры закрывают S3-бакеты по умолчанию после череды громких утечек.
Разработчикам же стоит воспринимать публичный anon-ключ как «ключ от входной двери, который видит каждый прохожий». Если за дверью нет замков (RLS), содержимое дома — общедоступно.
Итог
История с публичными утечками у клиентов Supabase — это не единичный инцидент, а системный симптом. Быстрый запуск приложений с помощью BaaS-платформ снижает порог входа, но одновременно перекладывает ответственность за безопасность на разработчика, который не всегда к этому готов. Пока RLS не станет включённой по умолчанию, а инструменты аудита — обязательной частью деплоя, подобные находки будут появляться снова и снова. Вывод прост: удобство не отменяет необходимости думать о безопасности — особенно когда речь идёт о персональных данных реальных людей.
FAQ
Что такое RLS и почему это важно?
Row Level Security — механизм PostgreSQL, позволяющий задавать правила доступа к отдельным строкам таблицы. Без него публичный API Supabase может отдавать любые данные всем желающим.
Виновата ли Supabase в утечках?
Формально ответственность лежит на разработчиках, которые не настроили политики безопасности. Однако критики указывают, что RLS не включена по умолчанию, что провоцирует ошибки.
Как проверить, не утекают ли мои данные?
Стоит проверить, включена ли RLS для всех таблиц в проекте, и убедиться, что политики не разрешают анонимный доступ к чувствительным данным. Также полезно ограничить права роли `anon` и провести аудит через встроенный линтер безопасности Supabase.