Сайт на Lovable собирают обычным описанием — например, просят сервис сделать форму заказа, кабинет клиента или доску объявлений. Если к нему подключена база Supabase, настройки определяют, кто читает и меняет каждую запись. Эту часть легко пропустить, пока приложение выглядит и работает как задумано.
Но важно понять, что именно нашли. В начале ноября немецкая компания Crissy Field сообщила о тысячах проектов Lovable, где исследователи нашли читаемые таблицы Supabase с адресами электронной почты. Отчёт описывает отдельные конфигурации, а не каждый сайт на платформе. Если вы собирали приложение сами, проверьте свой проект и его настройки доступа.
Коротко
- Откройте отчёт безопасности проекта Lovable, а затем Security Advisor в подключённом Supabase.
- Проверьте, включена ли защита RLS на таблицах с личными данными и кому дают доступ политики.
- Publishable-ключ в браузере работает вместе с правилами RLS. Secret-ключ храните только на сервере: у него расширенный доступ к базе.
- Работайте только со своим проектом и тестовыми учётными записями.
Что именно нашли исследователи#
Crissy Field изучила 159 041 проект Lovable, найденный в архиве Common Crawl с декабря 2025 по сентябрь 2026 года. Supabase использовалась в 34 545 проектах. Исследователи выделили 24 664 сайта, которые отдавали записи из базы при загрузке страницы без входа пользователя. Для новостей или каталога товаров это может быть ожидаемым поведением. Риск появляется, когда рядом с публичными записями видны чужие адреса, заказы или переписка.
Затем исследователи отправили дополнительные запросы только к этим сайтам и нашли адреса электронной почты в таблицах 7 403 из них. В примерах из отчёта встречались профили, сообщения, сведения о заказах и другие чувствительные данные. Исследование проводилось вместе с журналистом немецкого Handelsblatt; о нём также написала India Today.
У цифры 7 403 есть важные границы. Crissy Field отмечает, что найденный email мог быть публичным адресом или тестовой записью; личные строки без email метод не выявлял. Архив Common Crawl не представляет все приложения Lovable, а исследователи скачивали лишь части наборов данных. Значит, это количество сайтов, где обнаружились таблицы с адресами, а не статистика подтверждённых взломов. Отчёт охватывает Supabase, но не Lovable Cloud. Список чужих сайтов не подходит для самостоятельной проверки — ниже речь только о своём проекте.
Шаг 1. Убедитесь, что проект вообще использует Supabase#
В Lovable откройте нужный проект и посмотрите подключённые интеграции. Нашли Supabase? Сверьте его адрес с URL в окне Connect панели Supabase и сравните имя проекта и среду — тестовую или рабочую. Для статичной страницы без базы выводы исследования о Supabase неприменимы.
Если URL интеграции скрыт, попросите разработчика назвать подключённый проект и прислать только его адрес. Сверьте его с рабочей средой в Supabase. Если связку определить не удалось, остановитесь и уточните её у владельца проекта: проверка соседней базы ничего не скажет о сайте.
Шаг 2. Запустите проверку Lovable и разберите предупреждения#
По описанию Lovable, базовая проверка безопасности выполняется при публикации. Она смотрит на конфигурацию базы, правила RLS и настройки облачного проекта. Для более глубокой проверки у сервиса есть отдельный скан по запросу. Найдите результат проверки безопасности в рабочем пространстве и прочитайте каждое предупреждение до публикации изменений.
Но даже чистый отчёт дополняйте проверкой прав в Supabase и поведением сайта под разными ролями. Скан служит первым фильтром. Если инструмент предлагает автоматическое исправление, сперва посмотрите, какие настройки он изменит.
Шаг 3. Посмотрите Security Advisor в Supabase#
В панели Supabase откройте проект и выберите Advisors → Security Advisor — такой путь указан в справке сервиса. Проверьте предупреждения о выключенном RLS, широких правилах или доступе к таблицам. При другом названии пункта меню сверьтесь с этой справкой.
В Table Editor составьте короткий список таблиц и отметьте, какие данные каждая хранит и кто должен их видеть. Если владелец решил открыть каталог, его читают все; адрес заказа видят только владелец и администратор. Когда общие и личные сведения оказались в одной таблице, отложите публикацию изменений и попросите разработчика разделить записи или ограничить поля.
Возьмите одну тестовую строку и сверяйте доступ с её назначением. Гостю нужны только открытые владельцем сведения, владельцу — своя запись, администратору — данные, необходимые для работы. Это первичный разбор сценария; отдельная проверка RLS покажет, как база применяет такие правила.
Не включайте RLS вслепую
После включения Row Level Security (RLS) база проверяет правила для каждой операции. Без подходящих политик пользователь потеряет доступ к нужным данным, а форма может перестать работать. Составьте список ролей и действий, затем проверьте настройки в копии или тестовой среде.
Шаг 4. Настройте правила для своих таблиц#
Зачем здесь RLS? Этот механизм PostgreSQL ограничивает чтение и изменение строк по заданным условиям, как объясняет руководство Supabase. В личных заметках пользователь видит строки со своим идентификатором. Правило настраивают под структуру проекта: Supabase не знает, какие записи вы считаете личными, а какие публикуете для всех.
В каждой таблице, доступной через API, проверьте RLS и правила чтения, добавления, изменения и удаления строк. Право на чтение отделено от права менять данные. В таблице заметок пользователь получает строки, где user_id совпадает с его идентификатором; гостю доступны ноль личных заметок. Для публичных объявлений откройте чтение опубликованных строк, а запись и правку оставьте владельцу.
Политика «разрешить всем» может убрать ошибку на экране, но одновременно раскрыть данные. Grant задаёт базовый доступ роли к таблице, а RLS отбирает строки для этой роли; проверьте оба уровня. Когда смысл условия непонятен, передайте настройки разработчику до публикации.
Шаг 5. Разведите ключи для браузера и сервера#
Для подключения к Supabase используются ключи двух типов. Publishable-ключ рассчитан на браузер; права запросов задают grants и RLS. Актуальные ключи находятся в Supabase Settings → API Keys.
Secret-ключ предназначен только для серверного кода и обходит RLS. Храните его в настройках сервера. Если он появился в открытом коде или сообщении, выпустите замену в панели Supabase, обновите серверные настройки и проверьте приложение.
Ключ не заменяет права доступа
Publishable-ключ изначально открыт в клиентском коде; защиту данных обеспечивают RLS-политики и grants. Secret-ключ работает с расширенными правами и остаётся на сервере.
В старых проектах publishable-ключ может называться anon, а secret-ключ — service_role. С таблицей соответствий и шагами перехода можно свериться в справке Supabase по API-ключам.
Шаг 6. Проверьте сайт как гость и как другой пользователь#
Проверяйте свой проект сперва в тестовой среде. Откройте сайт в приватном окне или выйдите из аккаунта и убедитесь, что гость видит только те данные, которые владелец решил открыть всем; это может быть каталог или список событий. Затем войдите под тестовой учётной записью и сравните доступ к своей записи, чужой строке и данным администратора.
Создайте две тестовые заметки с разными владельцами и сравните результат. Гость видит только открытые владельцем данные, первый пользователь — свою заметку, второй — свою. Таблица профилей остаётся за авторизацией.
Сайт может скрывать чужую строку на экране, хотя база её отдаёт. Поэтому дополнительно проверяют серверное правило для гостя и обеих тестовых ролей. Разработчик подготовит тесты локальной базы и запустит их через Supabase CLI командой supabase test db после старта локального проекта. Команда выполняет написанные заранее тесты; сам запуск результата не создаёт. Если вы не работаете с SQL и правами базы, поручите эту проверку разработчику.
Пройдите обычный путь записи — создание, чтение, изменение и удаление. Когда правило блокирует нужное действие, уточните, какой роли оно требуется, и добавьте доступ только ей. После настройки снова запустите Advisor и security scan, затем проверьте публичную и авторизованную версии сайта.
Если проект уже был опубликован#
Доступ определяют настройки конкретного проекта. Если нашли таблицу, доступную без входа, сначала установите, должна ли она быть публичной. Меняйте правила точечно: полное закрытие рабочей базы остановит каталог, заказы или авторизацию. При личных сведениях и неясных политиках сохраните копию схемы и поручите специалисту определить доступ для каждой роли.
Если secret/service-role ключ оказался в открытом коде, сразу сообщите владельцу проекта и разработчику. В стандартном порядке сперва устраняют источник утечки, создают новый ключ, переключают на него серверные компоненты и проверяют работу приложения, а затем отзывают старый — так рекомендует Supabase. Если есть признаки, что утёкшим ключом уже пользуются посторонние, старый ключ отзывают сразу; серверные компоненты на нём перестанут работать. Если у вас нет доступа к Supabase, передайте владельцу проекта факт раскрытия и не пересылайте сам ключ в переписке. Ротация останавливает новые запросы со старым ключом, но не удаляет копии, которые могли сохранить раньше.
Если чужие пользователи могли читать личные записи, сохраните журналы и попросите специалиста оценить доступ и определить затронутые данные.
Короткая проверка перед следующей публикацией#
- Выбрана правильная среда и подтверждено, что база принадлежит вашему проекту.
- В Lovable просмотрены базовая и, при необходимости, глубокая проверки.
- В Supabase открыт Security Advisor, каждое предупреждение сопоставлено с моделью доступа.
- На таблицах с личными данными включён RLS, grants и политики соответствуют ролям.
- В браузере используется publishable-ключ; secret/service-role хранится на сервере. Тесты проведены гостем и тестовыми пользователями.
- В открытом доступе находятся только выбранные владельцем данные; личные строки доступны своим ролям.
Состав данных зависит от настроек конкретного проекта, а не только от Lovable или Supabase. Проверяйте доступ после крупных изменений и перед выпуском новой версии, особенно когда в приложении появились профили, заказы или сообщения.
Главное
Работайте только со своим проектом. Начните с Lovable Security Scan, продолжите в Supabase Security Advisor и проверьте RLS под тестовыми ролями. Когда права каждой таблицы вызывают вопросы, сначала покажите настройки специалисту и только потом публикуйте приложение.
MAX
Дзен
Telegram