Ошибки Supabase RLS: база пустая или запись не проходит

Lovable, Bolt и другие ИИ-инструменты активно используют Supabase и часто включают RLS (Row Level Security — защиту на уровне строк). Это правильно, но политики к нему ИИ пишет неполные. Отсюда два классических симптома: приложение показывает пустой список, хотя данные в таблице есть, или при сохранении появляется new row violates row-level security policy for table.

Почему так происходит

• RLS включён, политики нет. Postgres в этом случае по умолчанию запрещает всё. Чтение не выдаёт ошибку, а просто возвращает ноль строк — отсюда «пустая база».
• Есть политика на чтение, нет на запись. Для INSERT нужна политика с WITH CHECK, для UPDATE — и USING, и WITH CHECK.
• Пользователь не вошёл. Политика проверяет auth.uid() = user_id, а запрос идёт без сессии, значит auth.uid() пуст.
• Не заполняется user_id. Запись создаётся без владельца, и политика чтения её потом не находит.
• Обходы. Представления (view) в Postgres по умолчанию выполняются с правами владельца и могут показывать то, что RLS скрывает. Функции с security definer — тоже.

Что проверить самому

1. В Supabase → Table Editor у таблицы стоит отметка RLS enabled. Если RLS выключен — это дыра, а не решение.
2. Откройте Authentication → Policies и посмотрите, есть ли политики на все нужные операции.
3. В консоли браузера проверьте, что у запроса есть заголовок Authorization с токеном пользователя, а не только публичный ключ.
4. Проверьте, что в новых строках заполнено поле владельца.
5. Сверьте URL проекта в коде и в панели Supabase.

Минимальный набор для таблицы «мои заказы»:

alter table orders enable row level security;
create policy "read own" on orders for select
  using (auth.uid() = user_id);
create policy "insert own" on orders for insert
  with check (auth.uid() = user_id);

Для представлений в Postgres 15 и новее добавьте with (security_invoker = true), чтобы к ним применялись права вызывающего.

Когда звать разработчика. Для простой схемы «каждый видит только свои записи» политики выше можно применить самостоятельно. Помощь нужна, если в проекте есть команды, компании, менеджеры и администраторы с разными правами, если данные одного пользователя должны быть видны другому по приглашению, если политики начали тормозить запросы или если вы не уверены, что тестовый вход действительно проверяет чужие данные. Ошибка в политике RLS не видна в интерфейсе, а проявляется только тогда, когда кто-то её найдёт.

Как чиним мы

Составляем матрицу доступа: таблицы, роли, операции. Пишем политики под вашу логику, включая сценарии с командами, менеджерами и админами, где простое auth.uid() = user_id не подходит. Проверяем каждую роль отдельным тестовым пользователем, включая попытки прочитать чужие данные. Ищем обходы: представления, функции, места с секретным ключом. Если логика доступа сложнее, чем удобно выражать политиками, переносим её в серверный код. Подробнее — на странице «Аптечка вайб-кода», а общие причины поломок — в статье «Почему вайб-код ломается».

Сколько стоит

Диагностика — 50 000 ₸, аудит безопасности и настройка доступа — 60 000 ₸, итого от 110 000 ₸ для небольшого проекта. Если таблиц много и есть роли, применяется коэффициент размера. Рассчитайте в калькуляторе.