Коротко и по‑понятному — такое может происходить по двум большим причинам: сервер «перепутал» кого он сейчас обслуживает (смещение/перемешивание сессий или потоков) либо приложение неправильно работает с OAuth‑токеном/данными ЕСИА и показывает кэшированные/общие данные, не проверяя, что они действительно принадлежат текущему пользователю. Ниже — более развёрнуто, с конкретными сценариями, почему это возможно и как это проверить/устранить.
Что происходит «изнутри» (возможные механизмы)
1. Неправильное кэширование (самая частая причина)
- Прокси/CDN/обратный кэш (Varnish, nginx proxy_cache и т. п.) или внутренний кеш (Redis/Memcached) вернул ответ, сформированный для другого пользователя, потому что ключ кэша не включал уникальный идентификатор пользователя/токен/куку.
- Пример: API возвращало JSON с метаданными деклараций, а кэшировщик хранил его по URL без учёта заголовка Authorization или cookie → два пользователя видят один и тот же набор метаданных.
2. Ошибка авторизации / неверная проверка токенов
- Бэкэнд получает токен от ЕСИА, но не проверяет/не связывает корректно поле "sub" (идентификатор пользователя) или одноразовые атрибуты (aud, iss). В результате данные подставляются по org_id или вообще без привязки к конкретному пользователю.
- Если scope usr_org запрошен, система может сначала получить список организаций и затем по org_id подставлять метаданные — и если проверка «кто именно запрашивает данные этой организации» отсутствует, можно увидеть чужие данные.
3. Перемешивание сессий / некорректное хранение сессии
- Неправильная реализация сессий: общие static/глобальные переменные или thread‑locals, перезапись сессии при высокой нагрузке, идентичные session id на разных инстансах, коллизии в генерации id.
- Sticky‑session/балансировка: при переключении инстансов логика может путать куки и сессии.
4. Session fixation / cookie scope
- Кука сессии сформирована/передана некорректно (широкая область домена), другой пользователь браузера/машины получает ту же куку. Маловероятно в типичной вебсистеме, но возможно при ошибках конфигурации.
5. Побочная причина — неисправный logout / токен не отозван
- После “выхода” сервер/клиент не удалил все маркеры (cookie, localStorage), и при новом входе остаётся старое состояние или кэшированные фрагменты интерфейса.
Почему это могло сохраниться после выхода и повторного входа
- Кэшированные фрагменты интерфейса остались в серверном кэше и отдавались вновь при последующих запросах.
- Локальные данные в браузере (localStorage/sessionStorage) были неочищены.
- Бэкенд не выполнял привязку между текущей сессией и токеном ЕСИА — при повторном входе отдают последние загруженные метаданные, т.к. не проверяют владельца.
Как подтвердить причину (что попросить у ФТС/что смотреть в логах)
- Логи аутентификации: показать ID пользователя (sub/uin), время, session_id, IP, host/инстанс, correlation_id для каждого запроса.
- Логи запросов к кэшу/прокси: какие ключи кэша использовались, был ли кэш‑хит в момент, когда вы видели чужие данные.
- Сопоставление запроса к ЕСИА и последующего запроса сервисов данных: совпадает ли sub в токене с тем user_id, по которому были загружены метаданные.
- Логи инстансов приложений: какой процесс/host сформировал ответ; совпадают ли session_id и Authorization header.
- HAR: сравнить заголовки Authorization/ cookie / запросы за время «хорошего» и «плохого» окна.
Как это устранить (рекомендации для разработчиков ФТС)
- Никогда не кэшировать персональные/чувствительные ответы по URL без включения user id или Authorization в ключи. Настроить Vary: Authorization или запретить кэшировать для приватных эндпоинтов.
- На уровне приложения всегда проверять, что возвращаемые данные действительно принадлежат текущему пользователю (сравнение sub/uid токена и owner_id ресурса).
- Валидировать OAuth‑токены: проверять iss, aud, exp, sub, scope; при необходимости — делать introspection/запрос на ЕСИА.
- При логине/логауте — пересоздавать session_id, удалять все куки/локальное хранилище, отозвать/инвалидировать серверную сессию.
- Избегать глобального состояния/статических переменных для хранения текущего пользователя.
- Лимитировать время кэша и использовать отдельные namespace/ключи для tenant/organization‑aware данных.
- Логировать correlation_id и возвращать его в браузер, чтобы можно было быстро сопоставить проблемный ответ с серверными логами.
Что вы как пользователь можете сделать сейчас
- Сохранить HAR (вы уже сделали правильно) и передать его техподдержке с пометкой времени и URL.
- Попробовать повторить в другом браузере/инкогнито и посмотреть, воспроизводится ли.
- Попросить у ФТС логи с correlation_id/ session_id и проверку кэширования/прокси.
- Попросить полную проверку обработки scope usr_org: как они мапят org → ресурсы и как проверяют, что текущий пользователь имеет право просматривать эти ресурсы.
Короткая итоговая вероятность (на основе описания)
- Наиболее вероятно: неправильное серверное кэширование или ошибка в логике привязки токена ЕСИА (org→user mapping) — то есть не классический «угон» токена, а логическая/конфигурационная ошибка, из‑за которой отображаются чужие метаданные. Менее вероятно — утечка cookie/сессий, но это тоже нужно проверить.
Если хотите, могу помочь составить точный список логов и вопросов для техподдержки/разработчиков ФТС, которые стоит им передать — это поможет быстрее найти виновника.