Как проверить, что один клиент не увидит данные другого?

Чужой записи нет на экране. А сервис её отдаст?

Вход отвечает на вопрос «кто перед нами?». Право доступа отвечает на другой: «что этому человеку можно сделать с этой записью?». Пользователь может честно войти под своим именем и всё равно получить то, что ему не положено, если сервис проверяет только вход.

Представим условный сервис записи на консультацию. У первого клиента есть запись 101, у второго – 202. В кабинете второго показывается только 202. Однако разработчик открывает прямую ссылку на 101, оставаясь под вторым аккаунтом, и видит время, комментарий или вложение первого. Для этого примера правило нарушено: личная запись стала доступна постороннему клиенту.

Экран может скрывать чужие строки и ненужные кнопки. За ним работает сервер – часть сервиса, которая выдаёт данные и выполняет изменения. Она должна проверить право человека до выдачи записи или выполнения действия. Если данные уже пришли в браузер, а экран их просто не показывает, спрятанная строка не защищает содержимое.

То же относится к изменению. У второго клиента нет кнопки отмены чужой записи. Но если сервер принимает от него команду отменить 101, отсутствующая кнопка мало помогает. Убирать её с экрана полезно для удобства. Отказать в чужом действии должна рабочая часть сервиса.

Случайный номер для такого показа не подходит. Запись может просто не существовать. Для показа выберите существующую тестовую запись: сначала её открывает владелец, затем к ней обращается другой клиент. Иначе обычный сбой легко принять за защиту.

Сначала договоримся, кому что можно

Чтобы понять показ, сначала запишем ожидаемые права. В нашем условном сервисе клиент может читать, менять и удалять собственную запись. Чужую не может. Это выбранное правило примера. В вашем продукте удаление может быть запрещено даже владельцу, а изменение времени может заменяться запросом сотруднику.

Создайте с подрядчиком два обычных тестовых аккаунта: «Первый» и «Второй». Не используйте вход администратора вместо клиента. Для первого создайте запись 101 с комментарием «Проверка первого клиента», для второго – запись 202 с комментарием «Проверка второго клиента». Имена и содержание вымышленные. Настоящие обращения не нужны.

Составьте таблицу «роль – запись – действие». Для нашего правила она заполнена так:

Это двенадцать отдельных проверок: два клиента, две записи и три действия. Шесть действий разрешены, шесть запрещены. Таблица описывает, как сервис должен работать. Пока разработчик не показал действие, слова «нельзя» в ней остаются требованием.

Возьмите такой лист и рядом с ожидаемым правом запишите, что получилось. Заполненный условный пример для второго клиента и записи 101: «чтение – отказ, содержимое не пришло; изменение – отказ, комментарий остался прежним; удаление – отказ, запись осталась у первого клиента». Для собственного листа оставьте непроведённые проверки с пометкой «не проверено».

Не пытайтесь сразу описать все будущие должности. Начните с одного вида личной записи и двух обычных клиентов. Если сотруднику нужен доступ к записи, добавьте его отдельной строкой и назовите причину. «Это наш сотрудник» ещё не отвечает, должен ли он видеть все записи или только назначенные ему.

Как разработчик покажет отказ на двух аккаунтах

Теперь у нас есть правило, тестовые записи и список действий. Попросите подрядчика подготовить копию сервиса с вымышленными данными, где изменения и удаление не затронут клиентов. Если копия отличается от будущей рабочей версии, попросите подрядчика назвать различия, которые влияют на доступ. Показ подтверждает работу только той версии и тех настроек, которые проверили.

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

Начните с разрешённого действия. Первый клиент открывает 101 и видит свой комментарий. Второй открывает 202. Этот шаг подтверждает, что записи существуют и сервис работает. Если никто не может открыть ничего, запрет на чужую запись ещё не проверен.

Дальше под вторым аккаунтом разработчик обращается к 101 по известной прямой ссылке. Если номер записи не виден в адресе страницы, подрядчик проверяет запрос, который браузер отправляет серверу, и указывает в нём чужую тестовую запись. Самостоятельно угадывать номера, перебирать адреса или обращаться к настоящим чужим данным владельцу не нужно.

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

Надписи «доступ закрыт» недостаточно, если ответ всё же содержит чужой комментарий. При чтении проверьте с разработчиком, что содержимое записи не выдано. При изменении первый клиент заново открывает 101: комментарий должен остаться прежним. При удалении он проверяет, что 101 существует. Отказ виден в ответе сервиса и в сохранённом состоянии записи.

Повторите запрещённые действия в обратную сторону: первый клиент обращается к 202. Разрешённые изменение и удаление собственных записей тоже входят в таблицу. Удаление выполняйте последним; для повторного показа подрядчик заранее восстановит тестовые записи. Иначе следующая проверка опять упрётся в отсутствующий объект.

Сохраняйте результат короткими строками: дата, проверенная версия, аккаунт, запись, действие, ожидаемое право и наблюдение. Например: «Второй; 101; изменить комментарий; запрещено; сервер отказал, у первого комментарий прежний». Подрядчик может приложить запись экрана или описание запроса без секретов. Вам нужен результат, который можно повторить после исправления.

У записи бывают другие входы

Показ на прямой ссылке закрывает один путь. У той же записи могут быть список, поиск, прикреплённый документ или выгрузка. Если они есть в продукте, включите их в проверку. Защищённая карточка не помогает, когда рядом можно скачать чужое вложение.

Допустим, время записи 101 закрыто для второго клиента, но документ из неё открывается по отдельной ссылке. Это новый незакрытый путь. Разработчик должен показать право доступа и к документу. Если документ прикреплён к записи на экране, его доступ всё равно проверяют отдельно.

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

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

Отдельный случай – общая запись. Если два сотрудника одной компании по договорённости видят один документ, доступ второго не является ошибкой. В таблице сначала появится условие «участник этой компании», а затем проверка с пользователем другой компании. Нельзя объявлять любой доступ к записи другого человека нарушением без знания правил продукта.

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

Что считать результатом приёмки

В заполненном листе различайте три результата: «соответствует правилу», «правило нарушено» и «не удалось проверить». Если второму клиенту выдали 101 или приняли его изменение, правило нарушено. Если показ остановился из-за сбоя, это пока неизвестный результат. Сбой не превращается в отказ в доступе по желанию принимающего.

При нарушении запишите точное действие и отдайте его на исправление. В примере это может быть одна строка: «Второй клиент меняет комментарий 101». Приёмку этого правила не закрывайте, пока подрядчик не исправит причину и не повторит показ. Проверьте также разрешённое действие: после исправления первый клиент должен по-прежнему менять собственную запись.

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

Если все строки прошли, запишите: «В этой версии проверенные действия выполняются по согласованным правам». Из неё не следует, что сервис невозможно взломать. Мы не проверяли все способы входа, настройки размещения, восстановление аккаунта и остальные причины утечки. Для них нужна другая работа.

Моя рекомендация: если в сервисе будут медицинские документы, денежные действия, доступ нескольких организаций или сложные роли, заранее обсудите со специалистом по безопасности, что проверять перед запуском. Это решение зависит от цены ошибки и устройства сервиса. Обычный показ двух аккаунтов полезен и здесь, но не закрывает весь вопрос перед запуском.

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

Что попросить перед запуском

Чтобы проверить разделение доступа, попросите подрядчика показать права двух обычных тестовых клиентов на существующих вымышленных записях. Чтение, изменение и удаление проверяют отдельно, в обе стороны. Результат запишите рядом с заранее согласованным правилом.

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