RLS ломается не в политике, а в предположениях вокруг неё

RLS ломается не в политике, а в предположениях вокруг неё

Row Level Security в Supabase и Postgres часто включают «для галочки», а потом удивляются утечкам. Ошибка почти всегда одна: политика выглядит правильной, но зависит от данных из auth.uid(), join’ов или дефолтов, которые не совпадают с реальностью запроса.

Проверь базовый набор:
— есть ли deny-by-default для каждой таблицы
— покрыты ли SELECT, INSERT, UPDATE, DELETE отдельно
— не открывает ли политика доступ через OR с слишком широким условием
— не полагается ли она на поле, которое клиент может подменить при вставке

Отдельно смотри на service role, функции SECURITY DEFINER и view: они легко обходят ожидаемый контур, если выдали лишние права или забыли про search_path. Для чтения данных это особенно опасно: RLS не спасает, если обход идёт на уровне привилегий, а не политики.

Хорошая проверка простая: открываешь таблицу как анонимный пользователь, как обычный auth, как владелец записи и как админ-сервис — и сравниваешь результат. Если поведение везде одинаковое, значит RLS пока не работает как барьер.