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

Публичное и персональное надо развести до реализации

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

серверный слой интерфейса как граница, а не прокси ради прокси

Browser-facing слой принимает session cookie, но не пропускает её в ключ публичного кеша. Персональные маршруты помечаются private, no-store либо используют строго приватный кеш. Публичные справочники и контент получают отдельные URL/контракты без зависимости от пользовательской сессии.

Разделение кэша по пользовательскому сеансу почти всегда слишком широкое

Технически можно разделить кеш по cookie, но это быстро превращает общий кеш в миллионы почти одноразовых вариантов. Лучше разделять маршруты и данные архитектурно. Персонализация добавляется на клиенте или BFF поверх публичного каркаса.

Набор инвариантов

Ответ с account identifier никогда не имеет public cache directive. Публичный endpoint не меняет payload от наличия session cookie. BFF отбрасывает лишние заголовки при обращении к внутренним сервисам. CSRF-защита применяется к изменяющим состояние browser-командам.

Самый опасный отказ — не 500

Случайно публично закешированный персональный ответ может выглядеть как «успешный» запрос. Поэтому security test должен проверять cache headers и отсутствие пользовательских данных на public routes. Это не задача одного pentest: инвариант полезно держать в автоматических контрактных тестах.

Проверка границы персонализации

Самый надёжный способ защитить edge-кэш — физически разделить публичный и персональный ответ. Страница события, расписание или публичная статистика могут иметь общий cache policy; баланс, настройки пользователя и персональные действия должны идти через отдельный endpoint или BFF с явным private/no-store.

Попытка решить всё через широкий Vary: Cookie часто убивает эффективность кэша и всё равно оставляет риск ошибочной конфигурации. Чем проще правило — «этот URL никогда не содержит персональных данных» — тем легче проверить CDN, тестами и логами.

• Проверить ответы с разными cookies на CDN и origin.
• Не включать персональные поля в HTML, который планируется кэшировать публично.
• Логировать cache class и hit/miss без пользовательских секретов.

Самый важный тест — попытаться получить чужой персональный фрагмент

Проверка cache граница ответственности должна быть агрессивной: два аккаунта, одинаковый публичный URL, разные selections и permissions. Ответ для публичного shell обязан совпадать, а персональные части — приходить только из приватного пути. Любой HTML-фрагмент, где account state попал под общий CDN key, считается критической ошибкой даже без явного security incident.

EventPage удобно собирать из двух классов данных: кэшируемый контент события и персональный слой через BFF/API. Это сохраняет быстрый first render и не заставляет ставить Vary: Cookie на всю страницу.

Наблюдаемость должна показывать cache class и причины bypass. Если после релиза публичный hit rate резко упал, возможно, новый код случайно протащил персональный признак в общий ответ.

Наблюдаем класс кэша

В логах edge/BFF полезно писать не cookie, а рассчитанный cache_class: public, private, no-store. Тогда можно увидеть аномалию — например, персональный маршрут внезапно начал отдавать HIT — без раскрытия содержимого сессии.