Что делать, если GET запрос с ID клиента возвращает данные другого клиента
Что проверяют
Отличаете ли вы функциональный баг от утечки данных. Ответ уровня «вернулись неверные данные» закрывает вопрос хуже, чем ответ, где это нарушение разграничения доступа к персональным данным, то есть высший приоритет и отдельный канал сообщения.
Как отвечать
Сначала зафиксировать факт: точный запрос, заголовки, чей токен, время, идентификатор трассировки, тело ответа. Повторить в чистом окружении (приватное окно, консольный клиент, без прокси и расширений), чтобы исключить кэш браузера.
Дальше развести гипотезы, потому что причины дают разные баги:
- сервер не сверяет владельца ресурса с субъектом токена. Проверяется подстановкой чужого валидного идентификатора под своим токеном: ожидается отказ, а не чужие данные;
- ответ закэширован как общий. Смотрим заголовки кэширования и признаки промежуточного кэша, повторяем запрос другим пользователем;
- гонка на сервере: состояние переиспользуется между запросами, тогда баг плавает и ловится только параллельной нагрузкой;
- клиент показал ответ на предыдущий запрос, пришедший позже. Тогда на сетевой вкладке видно, что сервер ответил правильно.
В отчёт идут шаги, ожидаемое и фактическое, окружение, доказательства. Реальные персональные данные в трекер не выкладываются, они маскируются.
Где спотыкаются
Ставят среднюю важность и кладут баг в общую очередь. Здесь важность максимальная независимо от частоты воспроизведения, и сообщать нужно сразу, а не по расписанию отчёта.
Второе: проверяют только несуществующие идентификаторы, получают ошибку и закрывают тему. Ключевая проверка другая: чужой существующий идентификатор под своим токеном.
Третье: уходят читать код вместо того, чтобы сузить причину по симптомам. Тестировщик приносит воспроизведение и границы проблемы, и это ценнее догадки про конкретную строку.