В PWA после выхода видны данные прошлого клиента: что проверить в кешировании

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

Где браузер способен сохранить данные

• HTTP-кеш браузера и промежуточных узлов.
• Cache Storage, которым управляет service worker.
• IndexedDB и другие локальные хранилища приложения.
• Состояние открытых вкладок и сохранённое представление страницы.

Эти механизмы независимы. Удаление одного токена не очищает IndexedDB. Заголовок Cache-Control: no-store не заставляет произвольный код service worker отказаться от явной записи ответа в Cache Storage. Политику надо проверить на каждом уровне, где приложение сохраняет личные сведения.

Публичная оболочка не равна личному кабинету

Спроектируйте выход как отдельный сценарий

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

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

Если личные данные нужны офлайн, заранее определите модель угроз общего или потерянного устройства. Объём, срок хранения, механизм блокировки и очистки зависят от процесса. Автоматическое кеширование всех ответов «ради скорости» — плохая замена такому решению.

Проверка без чтения чужих реальных заказов

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

В браузерных инструментах посмотрите, откуда получен ответ: сеть, service worker, память или диск. Отключение кеша для одной вкладки разработчика не всегда воспроизводит обычное поведение пользователя. Повторите проверку в штатном режиме после установки новой версии приложения.

Исправление должно дойти до уже установленных копий

Новый код на сервере ещё не означает, что установленная PWA уже использует новую логику. Проверьте жизненный цикл обновления service worker и очистку хранилищ старых версий. Открытая вкладка может продолжать работать с прежним состоянием. Не показывайте сообщение «проблема устранена» только после успешного развёртывания: повторите сценарий на устройстве, где до обновления были загружены учебные личные данные. При обнаруженном раскрытии ограничьте дальнейший доступ и действуйте по процедуре инцидента; техническая очистка не заменяет оценку последствий.

Что можно проверить по заголовкам

Инструмент ниже разбирает введённый Cache-Control для личного ответа и отмечает публичное кеширование, положительные сроки хранения и отсутствие no-store. Это только один слой проверки. Даже корректный заголовок не доказывает, что личный ответ не записывается вашим JavaScript в отдельное хранилище.

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