Как проверить роли и права в no-code приложении
Приложение может скрывать кнопку редактирования, но все равно отдавать чужую запись по прямой ссылке или запросу API. Поэтому каждое действие нужно проверять от имени разных ролей и на данных разных владельцев.
Что учесть до начала работы
Скрытие кнопки или страницы не является проверкой доступа к данным.
Для приложения с чувствительными данными требуется профильная проверка безопасности до запуска.
Что подготовить
Что делать
Составьте матрицу разрешений
По строкам укажите объекты и действия: список, просмотр, создание, изменение, удаление, экспорт. По столбцам разместите роли и владельца записи.
Результат: Для каждой пары роль-действие есть явное разрешение или запрет.Подготовьте разные учетные записи
Создайте гостя, двух обычных пользователей, менеджера и администратора. У двух пользователей должны быть разные собственные записи.
Результат: Можно отличить доступ к своей и чужой записи.Проверьте прямой адрес
Откройте страницу чужой записи по сохраненной ссылке после смены учетной записи. Повторите проверку для списка, файла и административного маршрута.
Результат: Запрет действует независимо от навигации и скрытых кнопок.Проверьте изменение идентификатора
В тестовой среде замените ID своей записи на ID чужой в разрешенном запросе или адресе. Ожидайте отказ без раскрытия содержимого.
Результат: Доступ ограничен на уровне данных, а не только интерфейса.Проверьте массовые действия
Отдельно проверьте экспорт, удаление, изменение статуса, загрузку файла и приглашение пользователя. Эти действия часто имеют более широкие права, чем обычная форма.
Результат: Критичные действия разрешены только нужным ролям.Зафиксируйте доказательства
Для каждого теста сохраните роль, объект, действие, ожидаемый и фактический результат. Исправление принимайте только после повторной проверки запрета и разрешенного сценария.
Результат: Воспроизводимый журнал проверки прав.Промпт для матрицы ролей и тестов
Составь матрицу прав и набор ручных тестов для no-code приложения. Не предполагай, что скрытый элемент интерфейса ограничивает доступ. Роли: [гость, пользователь, менеджер, администратор]. Объекты: [пользователь, проект, заказ, файл и другие]. Действия: просмотр списка, просмотр записи, создание, изменение, удаление, экспорт, смена статуса, приглашение пользователя. Правила владения: [кто владеет записью и кто может видеть чужие]. Для каждой пары роль-действие укажи: разрешено или запрещено, условие владения, серверное правило, тест прямой ссылки или ID, ожидаемый ответ и риск ошибки. Добавь положительный тест разрешенного действия и отрицательный тест запрета. Не используй реальные данные и не предлагай проверку рабочей системы без разрешения.
Что проверить перед публикацией
Что чаще всего портит результат
Проверить только видимые кнопки
Откройте прямой адрес и повторите разрешенный запрос с ID чужой записи.
Использовать одну учетную запись
Нужны минимум два обычных пользователя с разными записями и отдельный администратор.
Забыть экспорт и файлы
Проверьте массовые выгрузки, прямые ссылки на файлы и фоновые действия отдельно от экранов.
Короткие ответы
Достаточно ли настроить роли в интерфейсе?
Нет. Правило должно ограничивать чтение и изменение данных на серверной стороне или в политике самой базы.
Какой результат должен получать пользователь без доступа?
Приложение не должно раскрывать содержимое записи. Конкретный код или экран зависит от платформы, но отказ должен быть одинаковым для прямой ссылки и обычной навигации.
Матрица доступа и отрицательные тесты no-code приложения
Права проверяют не только наличием нужной кнопки, но и невозможностью чужого действия. Для каждой роли перечислите чтение, создание, изменение, удаление, экспорт и администрирование по каждой сущности. Тестировщик использует отдельные аккаунты и прямые ссылки, потому что скрытый элемент интерфейса не всегда закрывает данные.
До начала заведите контрольную таблицу: идентификатор материала, версия входа, владелец, обязательный результат, доказательство, статус и дата. Для каждой ручной правки записывайте причину, а промежуточные файлы называйте так, чтобы нельзя было перепутать черновик и принятую версию. Правило остановки тоже задается заранее: критичная ошибка в факте, правах, данных, формате или воспроизводимости возвращает работу на соответствующий этап. После приемки попросите коллегу повторить одну ключевую проверку только по переданному комплекту. Если ему нужна история личного чата или устное пояснение автора, передача еще не завершена. Такой журнал нужен не ради формальности: он показывает реальную стоимость исправлений, не дает потерять ограничение при следующем обновлении и помогает расследовать расхождение без повторения всей работы.
Контрольный сценарий от входа до приемки
Разделить материал на контрольные единицы
Подготовьте список ролей, таблицу сущностей, правила владения строками, тестовые аккаунты, набор данных разных владельцев, публичные ссылки, автоматизации, интеграции, требования аудита и сценарии увольнения пользователя и разбейте материал на небольшие элементы, которые можно подтвердить отдельно. Для каждого элемента задайте идентификатор, источник, владельца и ожидаемый статус. Это не дает одной ошибке потеряться внутри общего вывода.
Обработать без скрытых исправлений
Выполните построение матрицы разрешений, настройку минимальных прав, вход под каждой ролью, положительные и отрицательные тесты, попытки прямого доступа, проверку экспорта и API, отзыв доступа и анализ журналов, сохраняя исходный порядок и обозначения. Если данных недостаточно, оставьте пустое поле или вопрос. Не исправляйте автоматически числа, имена, ссылки и формулировки, даже когда замена кажется очевидной.
Сверить рискованные элементы
Проверьте изоляцию записей, изменение чужих данных, массовый экспорт, скрытые поля, публичные представления, права интеграций, наследование роли, кэш после выхода, журналы действий и процедуру блокировки. Начинайте с элементов, влияющих на деньги, права, сроки, публикацию или возможность воспроизвести результат. Случайная выборка допустима только для низкорисковых повторяющихся элементов.
Передать вместе с картой контроля
Итогом служит матрицу доступа, тестовые сценарии и результаты, список найденных нарушений, подтверждение исправлений, перечень сервисных аккаунтов, процедуру выдачи и отзыва прав. Приложите карту проверок, версии исходников и список исключений. Коллега должен повторить ключевую сверку без устных пояснений автора.
Граница применимости
Визуальное скрытие поля не означает серверного ограничения. Возможности проверки зависят от платформы и тарифа. Для чувствительных данных требуется профильная оценка и журналирование за пределами простого ручного теста.
Критерии, которые нужно записать до начала
Что передать следующему участнику
Владелец системы получает подписанную матрицу, аккаунты теста, доказательства отрицательных проверок, журнал дефектов и процедуру регулярного пересмотра. Пароли и токены не включаются в общий отчет.
Ошибка, из-за которой результат выглядит надежнее, чем есть
Команда проверяет администратора и обычного пользователя, но забывает гостевые ссылки и старый аккаунт сотрудника. Другая ошибка - тестировать только разрешенные действия. Составьте обязательный список того, что каждая роль не должна уметь.
Коротко
Проверка ролей надежна только тогда, когда запрет сохраняется вне интерфейса: по прямой ссылке, при замене ID, в экспорте и при работе с файлами. Матрица прав делает эти ожидания явными и повторяемыми.