<b>RLS ломает не запросы, а ожидания: 6 правил, чтобы не открыть лишние строки</b>

<b>RLS ломает не запросы, а ожидания: 6 правил, чтобы не открыть лишние строки</b>

Row Level Security в Supabase и Postgres выглядит просто: включил политику и «всё защищено». На практике ошибка почти всегда в том, что политика проверяет не тот контекст, не тот столбец или не тот путь доступа. Особенно когда auth живёт отдельно, а данные читаются через несколько слоёв представлений и функций.

— Делай deny-by-default: без явной политики строка не должна проходить.
— Сверяй auth.uid() и user_id по одному типу, без неявных кастов.
— Для read и write используй разные политики: одна не должна случайно покрывать другую.
— Проверяй, что service role не попал в клиентский путь.
— Если есть join через views, убедись, что RLS не обходится через более «широкую» таблицу.
— Не храни бизнес-логику только в клиенте: RLS должна быть последней линией, а не первой.

Самый частый баг — политика написана правильно, но тестируется из сессии с повышенными правами. Тогда кажется, что всё работает, а в реальном auth запрос либо падает, либо, хуже, открывает лишнее.

Полезная привычка: для каждой таблицы держи 3 сценария проверки — владелец строки, чужой пользователь и неавторизованный доступ. Если хотя бы один сценарий неочевиден, политика ещё не готова.