Кэширование персонализированного контента на edge без утечек данных

Почему персонализированные страницы протекают через кэш

CDN не знает ваше приложение так, как знает ваша команда. Он видит URL, метод, несколько заголовков и правило кэша перед собой. Если два запроса выглядят одинаково на этом уровне, CDN может считать оба ответа одним кэш-объектом.

Именно так начинаются утечки. Приложение может знать, что Алиса и Бен — разные пользователи, но edge-кэш знает только то, по чему вы заставили его варьировать. Если Алиса первой открыла /dashboard и CDN сохранил тот HTML, Бен может получить версию Алисы, если правило говорит, что эту страницу можно переиспользовать.

Команды попадаются на этом, потому что сигналы логина сами по себе не исправляют плохое правило кэша. Куки ничего не меняют, если CDN игнорирует куки для этого маршрута. Заголовок Authorization ничего не меняет, если ключ кэша по‑прежнему использует только URL. Побеждает правило.

Даже короткая ошибка быстро распространяется. Если вы кэшируете персонализированную страницу на несколько минут, CDN может выдать чужие имя компании, баланс счета, недавние заказы или админ-меню многим людям, прежде чем кто‑то заметит. Скорость edge работает в обе стороны.

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

Поэтому начните с разделения. Публичный контент обычно может жить в общем кэше. Контент тенанта требует более строгих правил. Пользовательский контент требует наибольшей осторожности и во многих случаях вообще не должен попадать в общий CDN-кэш.

Разделите ответы на три корзины

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

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

Простой тест помогает: кто должен получать точно такой же ответ?

Если ответ — все, это публичное. Если ответ — все в одной учётной записи клиента, это контент тенанта. Если ответ — один авторизованный человек, это пользовательский контент.

Запишите реальные примеры, прежде чем трогать правила CDN. Не ограничивайтесь метками вроде /app или /dashboard. Перечислите конкретные страницы, API‑ответы и фрагменты. Команда, которая записывает pricing, workspace members и my profile, примет лучшие решения, чем команда, ограничившаяся «публично» и «приватно».

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

Где начинается смешение

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

Обычный пример — /dashboard. Неграниченный посетитель должен получить общий вид или приглашение войти. Вошедший пользователь должен получить свои данные. Если оба запроса используют один и тот же URL, а CDN кэширует только по пути, первый ответ может стать версией, которую все увидят некоторое время.

То же происходит и в менее очевидных сценариях. Приложение может менять HTML при наличии сессионной куки, но CDN не включает эту куку в свой lookup. Приложение может выбирать нужного тенанта по X-Tenant-ID, в то время как CDN по‑прежнему считает /reports одним общим объектом. Широкое правило может покрывать и безопасный публичный HTML, и приватный JSON, хотя им никогда не следует иметь одинаковое поведение кэша.

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

Глубокая персонализация усугубляет ситуацию. Шаблон страницы может выглядеть публично, но один небольшой блок показывает имя пользователя, тариф, непрочитанные уведомления или недавние элементы. Этот крошечный блок делает весь HTML-ответ приватным.

Проблема проста: приложение варьирует по состоянию пользователя, тенанта или обоим, а ключ кэша — нет. Если CDN видит только /dashboard, он считает всех посетителей одним человеком.

Разделяйте ответы перед кэшированием

Начните с картирования каждого ответа, который может отправлять ваше приложение. Риск редко в самом CDN. Проблема возникает, когда два разных ответа выглядят одинаково для кэша, потому что приложение не пометило их достаточно явно.

Практический проход прост. Запишите каждую страницу и маршрут API, который может возвращать данные аккаунта, данные тенанта или что‑то, что меняется после входа. Классифицируйте каждый маршрут только в одну корзину: публичный, тенант или пользователь. Затем решите, что должен смотреть кэш для этой корзины: путь, локаль, host, slug тенанта или состояние сессии.

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

Каждая корзина нуждается в разных входах для lookup. Публичным страницам часто достаточно URL и, возможно, локали. Страницы тенанта обычно требуют URL плюс что‑то стабильное, идентифицирующее тенант, например hostname или tenant slug. Пользовательские ответы требуют сигнала, специфичного для пользователя, и во многих случаях их не стоит помещать в общий CDN‑кэш вовсе.

Здесь команды становятся небрежными. Они кэшируют /dashboard только по пути, а потом удивляются, почему одна компания видит данные другой. Или кэшируют /api/me, потому что в тестировании это выглядит быстро, но кэш никогда не видит, кто именно сделал запрос.

Если маршрут смешивает корзины и вы не можете его чисто разделить, пропустите edge‑кэш для этого маршрута. Если приложение не может доказать, к какой корзине относится ответ, закрывайте доступ. Отправляйте запрос на origin и возвращайте ответ, который общий кэш не будет сохранять. Это медленнее, но медленное можно исправить. Утечка данных — нет.

Проведите финальную проверку с реальными аккаунтами перед релизом. Прогрейте кэш как Пользователь A в Тенанте A, затем запросите те же маршруты как Пользователь B в Тенанте B. Используйте чистый браузер и повторите поток. Проверяйте исходный код страницы и ответы API, а не только видимый UI. Если имена, квоты, счета или недавняя активность хоть раз пересекаются — этот маршрут в неправильной корзине.

Используйте сигналы кэша, соответствующие корзине

Сигналы кэша должны отвечать на один вопрос: кто может безопасно переиспользовать этот ответ? Если ответ шире реальной аудитории, CDN может отдать одному человеку чужую страницу.

Для действительно общих ответов держите всё просто. Используйте Cache-Control: public только когда каждый посетитель должен получать одно и то же тело, и убирайте куки из ключа, если они не меняют результат. Маркетинговая страница с случайной сессионной кукой всё равно должна кэшироваться как маркетинговая, а не как приватный дашборд.

Контент тенанта находится посередине. Если для каждого тенанта разные брендинг, тарифы или данные аккаунта, добавьте идентификатор тенанта в ключ кэша. Это может быть hostname или заголовок tenant, но только если он однозначно соответствует одному виду для тенанта. Если два тенанта могут случайно поделиться одним и тем же кэш‑записью, правило слишком широкое.

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

Простой шаблон хорошо работает во многих приложениях:

• Публичная страница: Cache-Control: public, s-maxage=300 и никаких кук в ключе кэша.
• Страница тенанта: общий кэш с идентификатором тенанта в ключе.
• Пользовательская страница: Cache-Control: private или отсутствие общего кэша.

Начинайте новые правила с короткого TTL, часто 30–120 секунд. Если правило неверное, плохой контент быстро истечёт, и вы сможете просмотреть логи, заголовки и реальные ответы, не дожидаясь часа, пока кэш очистится.

Простой пример для SaaS

SaaS‑приложение может разместить три очень разных типа ответов за одним и тем же CDN. Если смешать их, скорость перестанет быть преимуществом и превратится в утечку.

Возьмём продукт с публичной страницей цен, дашбордом тенанта и личным почтовым ящиком.

/pricing одинаков для всех, поэтому CDN может кэшировать её как публичную страницу. /t/acme/dashboard меняется по тенанту и иногда по региону, поэтому lookup кэша должен включать tenant slug и, при необходимости, регион. /inbox принадлежит одному человеку, поэтому его следует выводить из общего кэша или варьировать по пользовательскому сигналу.

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

Дашборд тенанта сложнее. Алиса из Acme открывает его в регионе US и видит метрики, брендинг и суммарное использование своей компании. Боб из Northwind открывает тот же продукт из Европы и никогда не должен увидеть данные Acme, даже если шаблон страницы почти одинаков.

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

Поймать плохие правила просто. Войдите как Алиса в одном профиле браузера и как Боб в другом, используя разные тенанты. Откройте холодные страницы, обновите тёплые страницы и сравните имена, счётчики, логотипы и региональные детали. Если Боб хоть раз увидит счётчик Алисы или Northwind получит брендинг Acme — корзины смешаны.

Ошибки, которые приводят к утечкам

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

Специальные режимы создают проблемы ещё чаще. Страницы предпросмотра, админ‑виды, имитация пользователя поддержкой и внутренние режимы QA меняют то, что показывает страница. Если такие ответы попадают в тот же путь кэша, что и обычный трафик, неверная версия может просочиться наружу.

Строки запроса — ещё одна ловушка. Разработчики могут полагаться на ?tenant=a или ?preview=1, в то время как CDN игнорирует некоторые параметры или нормализует их в одну запись кэша. Приложение думает, что запросы разные. Кэш думает, что они одинаковы.

Заголовки создают тихие сбои. Браузеры, мобильные приложения и серверные клиенты не всегда отправляют одинаковые куки, заголовки авторизации или accept‑заголовки. Правило, которое выглядит безопасным для браузерного трафика, может сломаться, когда мобильное приложение пошлёт более скромный запрос и попадёт в более широкий bucket кэша.

Очистки (purge) также создают ложное чувство уверенности. Кто‑то очищает страницу, видит свежий контент и думает, что проблема решена. Между тем устаревшие варианты могут оставаться на других нодах кэша, под другим хостом или за другой комбинацией заголовков. Пользователи продолжают получать старые персонализированные данные даже после очистки.

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

Быстрые проверки перед релизом

Релиз может выглядеть нормально в одном браузере и всё равно протекать в продакшне. Самый надёжный тест — запросить один и тот же маршрут под разными идентичностями и убедиться, что CDN, приложение и браузер видят правильную версию.

Короткий набор проверок ловит большинство плохих настроек:

• Запросите один и тот же URL как гость, админ тенанта и обычный пользователь, затем сохраните заголовки запроса и ответа.
• Повторите те же запросы во втором тенанте и во втором профиле браузера.
• Выйдите из системы, перезагрузите маршрут и подтвердите, что ответ изменился.
• Очистите кэш или задеплойте, затем следите за устаревшими вариантами несколько минут.

Переключение тенанта — место, где многие утечки проявляются. Маршрут может варьировать по куке или токену авторизации, но CDN может игнорировать идентификатор тенанта и переиспользовать первый кэш‑объект. Эта ошибка часто скрывается, пока кто‑то не принадлежит двум рабочим областям и не переключается между ними.

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

После очистки или деплоя продолжайте наблюдать за устаревшим контентом. Некоторые edge‑узлы обновляются в разное время, а некоторые браузеры хранят свои копии. Если неверная страница пережила purge, остановитесь и найдите слой, который её удержал, прежде чем пускать больше трафика.

Что делать дальше

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

Небольшой аудит обычно достаточен. Выберите 10–20 маршрутов, где встречаются аутентификация, контекст тенанта и кэшируемый HTML или JSON. Если один пользователь мог бы увидеть имя другого, баланс, настройки или брендинг тенанта — ставьте этот маршрут в начало списка.

Затем напишите по одному короткому набору правил для каждой корзины и договоритесь между командой приложения и командой CDN об одних и тех же названиях: public, tenant и user. Такое простое разделение снимает много путаницы. Это также облегчает code review: у каждого маршрута будет ожидаемое поведение кэша вместо расплывчатой метки «персонализировано».

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

Полезен и простой тестовый скрипт. Запрашивайте один и тот же URL как Пользователь A, Пользователь B, Тенант A и Тенант B. Если CDN возвращает один и тот же кэш‑объект там, где не должен — вы хотите поймать это в staging, а не после клиентов.

Если нужна вторая проверка, Oleg Sotnikov at oleg.is делает такие аудиты границ CDN, аутентификации и тенантов в рамках своей advisory как Fractional CTO. Это помогает, когда стек вырос и никто уже точно не помнит, какой слой отвечает за правила кэша.

Самый безопасный следующий шаг обычно узкий и скучный: проверьте самые рискованные маршруты, держите split public/tenant/user чистым и добавьте оповещения, которые срабатывают в тот же момент, когда кэш нарушает этот контракт.