Если service worker кеширует страницу с чужими данными, это критичный сценарий: один пользователь может увидеть личный кабинет, заказ, имя или другую персональную информацию другого человека.
Персональные страницы и API с приватными данными нельзя кешировать как обычную статику. Нужно разделить public assets и authenticated content.
Коротко: что сделать
- Проверить стратегии кеширования service worker
- Найти, какие URL попадают в Cache Storage
- Проверить личный кабинет, заказы и API пользователя
- Проверить logout и очистку приватного кэша
- Проверить HTTP-заголовки Cache-Control
Основные причины
У таких сбоев редко бывает одна универсальная причина. Надежнее идти от факта к факту: где ошибка проявляется, какие данные проходят через систему, что изменилось перед поломкой и на каком шаге цепочка перестает работать.
- Стратегия cache-first применена ко всем GET-запросам
- HTML личного кабинета попал в precache
- API с cookie кешируется без учета пользователя
- После logout кэш не очищается
- Нет разделения public и private routes
Пошаговая диагностика
Диагностику лучше проводить на одном воспроизводимом примере. Так проще увидеть не общий шум, а конкретное место, где интерфейс, сервер, интеграция или внешняя служба начинают вести себя неправильно.
- Открыть DevTools Application и Cache Storage
- Войти одним пользователем, затем выйти и войти другим
- Проверить offline mode для личных страниц
- Посмотреть service worker routes
- Проверить заголовки no-store для приватных ответов
Как исправить проблему
Исправление должно закрывать первопричину, а не только маскировать симптом. Если затронуты доступы, платежи, данные клиентов или серверные настройки, сначала сделайте резервную копию и проверьте правку на тестовом сценарии.
- Исключить личные URL и API из runtime cache
- Добавить Cache-Control: no-store для приватных данных
- Очищать приватные caches при logout
- Кешировать только статику и публичные страницы
- Версионировать service worker и корректно обновлять клиентов
Безопасный план решения
Сначала отключите кеширование приватных маршрутов и проверьте сценарий двух пользователей. Только после этого оптимизируйте скорость PWA для публичной части.
Чего не стоит делать
- Не кешировать все GET-запросы подряд
- Не добавлять личный кабинет в precache
- Не хранить персональные данные в Cache Storage без строгой привязки
- Не считать logout достаточным без очистки кэша
Что подготовить перед исправлением
- Файл service worker
- Список приватных URL и API
- Сценарий, где видны чужие данные
- Заголовки ответа личной страницы
FAQ
Нужно ли полностью удалить service worker?
Не обязательно. Чаще достаточно исправить стратегии кэша и очистку приватных данных.
Почему это опасно?
Потому что пользователь может увидеть данные другого аккаунта даже без доступа к серверу, просто из локального кэша.
Что кешировать безопасно?
Статику: CSS, JS, шрифты, публичные изображения и публичные страницы без персональных данных.
Когда стоит обратиться за помощью
Обращаться стоит сразу, если есть риск показа чужих данных, заказов, телефонов, документов или личного кабинета.
Итог
Исключите приватные маршруты из service worker cache, добавьте no-store и очистку при logout. Если нужно быстро закрыть риск утечки в PWA, пишите в Telegram @rabotator_support.