Ошибки кэширования на стороне клиента: не показывайте чужие данные пользователей

Как выглядит «чужие данные» в реальных приложениях

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

Часто это случается при:

• Выходе из аккаунта и входе под другим
• Переключении рабочих пространств/организаций
• Изменении роли (админ → участник или наоборот)
• Обновлении токена и сценариях «запомнить меня» на общих устройствах

Простой пример: вы тестируете приложение на общем iPad. Вы входите как Клиент A, просматриваете заказы, затем выходите. Коллега входит как Клиент B и открывает заказы. Приложение показывает список Клиента A, потому что кэшированный ответ был сохранён под общим ключом вроде "orders" вместо ключа, скоупнутого по пользователю вроде "orders:userId".

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

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

Где на клиенте может храниться кэш (короткая карта)

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

1) Встроенный HTTP‑кэш браузера

Браузеры могут кешировать GET‑запросы на основе URL, заголовков и правил кэширования. Если ответы API отличаются для разных пользователей, но ответ помечен как кэшируемый, браузер может отдать предыдущий ответ даже после выхода и повторного входа.

Для аутентифицированных JSON API это случается реже (они обычно не кэшируются), но возможно при отсутствии нужных заголовков или неправильной конфигурации прокси/CDN.

2) Кэши на уровне приложения под вашим контролем

Большинство проблем с чужими данными приходят от кэшей внутри приложения:

• Состояние в памяти (глобальные сторы, синглтоны, переменные на уровне модуля)
• localStorage/sessionStorage (сохраняется между вкладками и перезагрузками)
• IndexedDB (часто в офлайн‑первичных приложениях)
• «Сохранённые ответы» для производительности

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

3) Библиотеки получения данных с кэшем запросов

Библиотеки вроде React Query, SWR, Apollo и RTK Query кешируют результаты по ключу, который вы задаёте (или который генерируется). Если этот ключ не учитывает текущий контекст идентичности, библиотека может отдать закэшированный результат из предыдущей сессии.

Это часто выглядит так: «переключаю аккаунт, и виджет профиля всё ещё показывает старое имя, пока не обновишь страницу».

4) Service workers и офлайн‑кэши

Service worker’ы могут кэшировать HTML, ответы API и ассеты. Если правила кэширования слишком широки, они могут сохранить персонализированные ответы API и воспроизвести их в офлайне или при ненадёжном соединении.

5) Рассинхронизация при SSR/CSR гидратации

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

Аудит ключей кэша, чтобы пользователи не сталкивались

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

Безопасный ключ описывает одновременно:

• какие это данные, и
• для кого эти данные предназначены (и в каком скоупе).

Хорошее правило: если изменение может изменить то, что сервер имеет право вернуть, ключ кэша тоже должен меняться.

На практике ключи (или неймспейсы) обычно должны включать:

• ID пользователя (или другой стабильный идентификатор аккаунта)
• ID тенанта/организации/рабочего пространства (для мульти‑тенантных приложений)
• Роль или скоуп прав (админ vs участник)
• Локаль (если контент меняется по языку/региону)
• Форму запроса: фильтры и пагинация

Избегайте ключей вроде "me", "profile", "dashboard" или "inbox", если они явно не скоупнуты под пользователя.

• Плохо: "profile" или "me"
• Хорошо: user:123:org:55:profile

Та же идея для списков:

• Плохо: "orders?page=1"
• Хорошо: user:123:org:55:orders?status=open&page=1

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

Правила инвалидации кэша, соответствующие реальным действиям пользователей

Большинство багов с чужими данными несложны. Приложение продолжает использовать данные, которые пять минут назад были корректны, но для другого человека.

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

Простое правило: когда «контекст текущего пользователя» меняется (ID пользователя, ID org/workspace), воспринимайте это как мини‑перезагрузку данных, скоупнутых по пользователю.

Практические триггеры для подключения:

• Вход, выход, переключение аккаунтов: очищайте кэши, скоупнутые по пользователю, отменяйте выполняющиеся запросы, повторно запрашивайте важное.
• Любое изменение видимости: смена роли/прав, переключение org/project.
• События авторизации: ошибки обновления токена, принудительный повторный вход, ответы «сессия истекла».

TTL — это не только настройка производительности. Это и контроль приватности. Публичный контент может жить дольше, но всё, что связано с идентичностью (профиль, биллинг, права, недавняя активность), должно истекать быстрее, особенно на общих устройствах.

Держите сбросы кэша простыми и централизованными. Создайте одну функцию (например, resetUserState()) которая очищает нужные кэши и реинициализирует приложение, и вызывайте её при входе/выходе/переключении. Если логика сброса разбросана по экрану, рано или поздно что‑то будет упущено.

Пошагово: воспроизведите и отладьте проблему

Самый быстрый путь починить баг — уметь воспроизводить его по требованию. Используйте один профиль браузера (или одно тестовое устройство) и два тестовых аккаунта с явно разными данными (разные имена, аватары и хотя бы одна уникальная запись).

Записывайте точные клики. Малые детали важны: какая вкладка была открыта первой, использовались ли назад/вперёд, выходили ли вы полностью или просто переключились.

Раннанет, который часто обнаруживает утечку:

• Войдите как Аккаунт A и откройте страницу, где позже появятся неправильные данные.
• Не закрывая вкладку, выйдите. Войдите как Аккаунт B. Перейдите на ту же страницу тем же путём навигации (включая назад/вперёд, если вы использовали).
• Просмотрите хранилище браузера (Local Storage, Session Storage, IndexedDB) и панели кэша. Ищите записи, которые не изменились при смене аккаунта.
• Вставьте временные логи вокруг чтения и записи кэша: логируйте ключ кэша, текущий идентификатор пользователя и откуда пришли данные (память, хранилище, сеть).
• Проверьте Network. Если ответ сервера для Аккаунта B, а UI показывает A, баг на клиенте.

Быстрый признак: если оба пользователя попадают под один ключ вроде profile:me, вы можете прочитать профиль A после входа B. Логи ключа плюс текущего ID делают это очевидным.

Сценарии на общих устройствах и с множественными аккаунтами для тестирования

На общих устройствах это быстро становится неловко. «Выход» часто очищает токен, но не кэшированные данные, полученные с этим токеном.

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

Использование нескольких аккаунтов в одном браузере — ещё одна проблема. Две вкладки могут иметь разные состояния сессии, особенно если одна обновляет токены или реинициализирует состояние, пока другая всё ещё рендерит старое. Если кэш глобальный (не скоупнут по идентичности), коллизии становятся вероятными.

Кнопка «назад» — особый случай. Некоторые браузеры держат страницы в памяти с помощью back‑forward cache (bfcache). После выхода пользователь может нажать назад и мгновенно увидеть предыдущий экран, включая закэшированные данные, до того как приложение снова выполнит проверки авторизации.

Прогоните эти тесты перед релизом:

• Войдите как Показатель A, откройте тяжёлую по данным страницу, выйдите, затем войдите как B без перезагрузки браузера.
• Повторите на общем устройстве и также закройте и снова откройте вкладку после выхода.
• Откройте две вкладки: в первой войдите как A, во второй как B, затем обновите обе и следите за смешением UI.
• После выхода нажмите Back и убедитесь, что вы никогда не видите данные A, даже кратковременно.

Подводные камни service worker и офлайна

Service worker’ы ускоряют работу, но могут воспроизвести данные не того пользователя. Самый большой риск — использовать cache‑first или stale‑while‑revalidate для запросов, зависящих от того, кто вошёл.

Пример: общий планшет в магазине. Пользователь A входит и открывает дашборд, затем выходит. Позже пользователь B входит, но service worker выдаёт кешированный ответ для /api/me или /api/orders до того, как сеть обновится. На момент (или дольше, если сеть упала) B увидит данные A.

Cache‑first и stale‑while‑revalidate обычно подходят для публичных статических файлов (app shell, иконки, CSS). Для endpoint’ов, скоупнутых под пользователя, они опасны, особенно когда URL не содержит идентификатор пользователя и опирается на cookie или bearer‑токен.

Когда сомневаетесь — обходите кэш для всего, что связано с идентичностью:

• Endpoint’ы вроде /api/me, /api/profile, /api/billing, /api/orders
• Любые запросы с заголовком Authorization
• Всё, что возвращает PII (имейлы, адреса, счета)

Если вы меняете правила входа/выхода, обновления токенов или ролей, считайте это ломкой для кэшей. Версионируйте кэши (например, app-v5) и удаляйте старые кэши при активации — иначе старые ответы будут появляться, даже после фикса.

Офлайн‑режим требует дополнительной осторожности. Храните офлайн‑данные строго по пользователю и очищайте их при выходе. Если вы храните очереди запросов или кэшированные ответы API, включайте текущий ID пользователя в ключи хранения и отказывайте в чтении, когда меняется подписанный пользователь.

Проверки безопасности и приватности (простые, но критичные)

Если кэш на клиенте показывает данные не того человека, рассматривайте это сначала как инцидент безопасности, а уже потом как UI‑баг.

Ключевое правило: никогда не полагайтесь на клиентский кэш, чтобы определить, кто имеет доступ. Закэшированное состояние может быть устаревшим, загрязнённым или скопированным между сессиями. Авторизация должна проверяться на сервере каждый раз.

Короткая проверка реальности: если кто‑то изменит ID пользователя в запросе (или повторит старый запрос), вернёт ли сервер данные? Если да, проблема не только в UI.

Минимум проверок, которые стоит выполнить:

• Проверьте, что каждый endpoint на сервере проверяет идентичность и скоупит данные под неё.
• Убедитесь, что выход инвалидирует сессии и refresh‑токены на сервере, а не только состояние UI.
• Сведите к минимуму чувствительные данные в долгоживущем хранилище (localStorage, IndexedDB). По возможности держите их в памяти.
• Убедитесь, что кэшированные ответы не делятся между аккаунтами на одном устройстве.
• Поиск по коду на предмет открытых секретов или захардкоженных токенов.

Ещё пример: если UI кратковременно показывает закэшированный "/me" профиль после выхода — это плохо. Если при этом сервер продолжает принимать старые токены, хуже: следующий человек сможет загрузить реальные данные, а не только устаревшие пиксели.

Частые ошибки, приводящие к показу чужих данных

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

Частые причины:

• Глобальный стор или синглтон переживает выход, и следующий вход наследует данные предыдущего пользователя.
• Запросы, начатые до выхода, завершаются позже, и их ответы записываются в кэш новой сессии.
• Ключи кэша слишком общие (/me, dashboard) и не включают пользователя, тенант, роль или окружение.
• Оптимистичные обновления пишут в общий кэш без проверки активного скоупа пользователя.
• Выход очищает только видимое (UI), но оставляет источник истины (память, хранилище, кэши service worker).

Две быстрые проверки, которые ловят многое:

1. Выйдите, затем войдите другим пользователем при ограниченной скорости сети. Наблюдайте, что рендерится до завершения первого нового API‑вызова.
2. Запустите медленный запрос, выйдите в процессе загрузки, затем войдите снова. Если медленный ответ прилетает и обновляет новую сессию — у вас проблема с «in‑flight» записью.

Быстрый чек‑лист перед релизом фикса (кэш и идентичность)

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

Тестируйте на одном устройстве и профиле браузера (именно там происходит большинство сюрпризов):

• Сделайте A→B swap: войдите как A, откройте тяжёлые по данным экраны, выйдите, затем войдите как B и вернитесь на те же экраны.
• Убедитесь, что ключи кэша везде скоупнуты по идентичности (память, query‑кэши, localStorage, IndexedDB).
• Сделайте выход полным сбросом: очищайте токены, refresh‑токены, кэшированные ответы API, персистентные сторы и значения «последнего выбранного аккаунта».
• Рассматривайте переключение аккаунтов как более серьёзное событие, чем обычная навигация: инвалидируйте user‑scoped запросы, отменяйте выполняющиеся запросы и повторно запрашивайте под новой идентичностью.
• Проверьте поведение service worker: версионируйте кэши при деплое и не отдавайте пользовательские ответы API из общих кэшей.

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

Следующие шаги: закрепите фикс

Выберите одно правило приёмки и сделайте его неоспоримым: после выхода (или переключения аккаунта) приложение не должно показывать данные предыдущего пользователя ни на секунду. Используйте эту фразу как руководство для ручного тестирования и автоматизированных тестов.

Практический порядок работ, который ловит большинство проблем:

• Сначала исправьте ключи кэша, чтобы они были скоупнуты по user/org/role.
• Сделайте так, чтобы выход и переключение аккаунта очищали user‑scoped кэши, сбрасывали состояние в памяти и отменяли выполняющиеся запросы.
• Проверьте правила service worker и уберите кэширование для аутентифицированных endpoint’ов, если вы не уверены в безопасности подхода.
• Добавьте один автоматизированный тест «Пользователь A затем Пользователь B», чтобы предотвратить регрессии.

Если вы работаете с AI‑сгенерированной кодовой базой (инструменты вроде Lovable, Bolt, v0, Cursor или Replit), эти проблемы особенно часты: паттерны копируются непоследовательно. FixMyMess (fixmymess.ai) фокусируется именно на диагностике и исправлении таких ситуаций — коллизий ключей кэша, неверной очистки при выходе и ошибок в правилах service worker — и может начать с бесплатного аудита кода, чтобы точно указать, откуда идут чужие данные.