Чтобы проверить доступ к данным приложения, войдите двумя учебными пользователями и попробуйте прочитать, изменить и удалить чужую запись напрямую через API. Скрытая кнопка в интерфейсе не доказывает, что сервер запрещает действие.
Что подготовить
Нужны отдельная тестовая среда, пользователи A и B и записи с вымышленными данными. У каждой записи должен быть владелец. Запишите правило приложения: например, пользователь видит и меняет только свои записи, а без входа не видит ничего.
В Supabase правила доступа к отдельным строкам называются RLS. Для таблиц, доступных через Data API, проверьте и права на таблицу, и RLS. Проверка из SQL-редактора с правами администратора не заменяет запрос от обычного пользователя.
Как выполнить проверку
- Попросите Codex составить таблицу разрешённых действий до изменения правил.
- От имени A прочитайте запись A. Затем запросите запись B по её точному ID. Повторите от имени B.
- Проверьте создание, изменение и удаление отдельно. Попробуйте создать запись с чужим владельцем и поменять владельца своей записи.
- Повторите запрещённые запросы без входа. Используйте способ подключения, который действительно передаёт права проверяемого пользователя.
- После каждой попытки сравните данные с исходным состоянием. Ответ без ошибки может означать, что изменено ноль строк.
| Проверка | Ожидаемый результат для учебного правила |
|---|---|
| A читает запись A | Запись получена |
| A читает или меняет запись B | Чужие данные не получены и не изменены |
| A создаёт запись для B | Запись не создана |
| A меняет владельца своей записи на B | Изменение отклонено |
| Посетитель без входа читает данные | Данные не получены |
Для UPDATE в Supabase нужна соответствующая политика SELECT. Условия USING и WITH CHECK позволяют проверить исходную и получившуюся строку. Серверный secret или service_role может обходить RLS; такой ключ не подходит для проверки пользовательской изоляции и не должен попадать в браузер. Документация RLS.
Промпт для Codex
В тестовом приложении пользователь видит и меняет только свои записи.
Сначала изучи текущую схему и правила доступа. Составь проверки для A, B и посетителя без входа: чтение, создание, изменение, удаление и подмена владельца.
Используй вымышленные данные и права самого пользователя, без административного обхода.
Для каждой проверки сохрани ожидаемый результат, ответ сервера и состояние данных после запроса. Если среда недоступна, дай план и явно отметь, что тест не выполнен.
Расширенный вариант: Спроектировать и проверить права данных. Подготовка среды: тестовая публикация.
Если проверка не прошла
При доступе к чужой записи остановите использование реальных данных и найдите правило, которое разрешило запрос. При отказе в доступе к своей записи проверьте вход, владельца, права на таблицу и политики. Сохраните прежние правила до исправления, затем повторите всю таблицу проверок.
Источники и границы проверки
Таблица задаёт ожидаемые результаты, а не подтверждает безопасность вашего приложения. Выполните запросы от двух обычных пользователей в выбранной среде и сравните ответы с таблицей.
