Row-Level Security для корпоративных данных с Supabase RLS
Перенос авторизации из клиентского кода в базу данных: основные принципы, которые следует учитывать при проектировании политик Row Level Security.
Одна из самых частых ошибок в корпоративных приложениях — реализация контроля доступа исключительно на уровне интерфейса. Предполагается, что скрытая кнопка защищает данные, однако для того, кто отправляет запросы напрямую к API, этой кнопки никогда и не существовало.
Авторизация должна осуществляться на уровне базы данных
Функция Row Level Security в PostgreSQL позволяет задавать условия политик, которые автоматически добавляются к каждому запросу. Supabase объединяет эти политики с данными аутентификации: с помощью функции auth.uid() она определяет пользователя в сеансе и возвращает только разрешенные строки.
Не доверяйте данным, которые может изменить пользователь
Хранить информацию о ролях в метаданных пользователя заманчиво, но зачастую это поле может быть обновлено на стороне клиента. Более безопасным подходом является хранение ролей в отдельных таблицах и их проверка с помощью функций security definer.
Контрольный список
- Включите RLS для каждой таблицы и по умолчанию запретите любой доступ.
- Ограничьте политики анонимного чтения только публичным контентом.
- Привяжите операции записи к таблицам авторизации.
- Проверяйте политики с помощью автоматических тестов.
Этот подход также лежит в основе панелей управления, которые мы разрабатываем в Cy Logic.