Подготовим две вымышленные записи

Это учебный пример на бумаге. Все аккаунты, клиенты, договоры и суммы ниже вымышлены. Вы можете выполнить эти проверки в своём учебном проекте и записать фактические результаты.

Учебный аккаунт Разрешённая клиентская запись Номер договора Сумма
A A-001 HT-A-01 10000 CNY
B B-001 HT-B-01 20000 CNY

Первая версия позволяет после входа найти договор по номеру записи, только если аккаунт имеет к ней доступ. Добавление, изменение и экспорт пока не входят в задачу.

Как могла бы возникнуть ошибка

Предположим, что вход есть, но API ищет только по введённому номеру записи. A вводит A-001 и получает свой договор, а по B-001 получает и договор B.

В этом предположении запрос не ограничивает область данных. Если страница показывает только клиентов A, это ещё не защищает API: запрос можно изменить или отправить другим способом.

Как организовать запрос на сервере

  1. Получать текущую личность из уже проверенного состояния входа. Без входа отказывать в чтении ограниченных данных.
  2. Искать введённый номер только в области, доступной этой личности. Не доверять аккаунту, который отправитель сам указал в запросе.
  3. Если доступной записи нет, вернуть сообщение без содержимого договора. На странице можно написать: «Доступные данные не найдены».

В реальной системе права могут зависеть от человека, команды или других правил бизнеса. Сначала опишите эти правила, затем выбирайте структуру данных и способ реализации.

План проверок после изменения

Ниже — план тестирования и ожидаемые результаты. Их нужно реально проверить в своём учебном проекте.

Состояние входа и действие Ожидаемый результат
A запрашивает A-001 HT-A-01, сумма 10000 CNY
A запрашивает B-001 Нет договора и суммы B
B запрашивает B-001 HT-B-01, сумма 20000 CNY
B запрашивает A-001 Нет договора и суммы A
Без входа напрямую запрашивают A-001 Чтение отклонено, содержимое договора не возвращается
A обращается к B-001 напрямую, минуя страницу Права по-прежнему проверяются, данных B нет
A вводит несуществующий номер Понятное сообщение без содержимого других договоров

Сохраняйте роль аккаунта, ввод и фактический результат каждого теста. Проверяйте весь ответ: в нём не должно быть лишних записей, скрытых на странице. Проверка только видимого текста может пропустить избыточные данные API.

Сохраняйте правило при добавлении новых способов чтения

Если появятся поиск, экспорт или вопросы к ИИ, убедитесь, что они используют ту же область доступа. Системные права должны определять и то, какие данные ИИ может читать перед ответом.

Эти проверки в основном касаются чтения между аккаунтами. Для полного проекта нужно по функциям проверить также обработку ввода, права изменения, журналы, публикацию, резервные копии и другие вопросы. Дополните подходящие пункты из чек-листа публикации, а задачу начните с описания на одной странице.

Частые вопросы

Это реальный клиентский проект?
Это вымышленный пример на бумаге. Аккаунты, клиенты и договоры — учебные данные. Таблицы содержат план проверок для своего проекта, а не отчёт об уже выполненном тестировании.
Почему при наличии входа могут открыться чужие данные?
Вход подтверждает личность. Серверные запросы должны дополнительно ограничивать данные по этой личности. Если искать только по клиенту или номеру записи, личность вошедшего пользователя может вообще не участвовать в проверке прав.

Читать дальше

Записаться на бесплатные 15 минут Стоимость и содержание