Новая политика рефереров по умолчанию для Chrome — strict-origin-when-cross-origin.

Мод Налпас

Прежде чем начать:

  • Если вы не уверены в разнице между "site" и "origin", ознакомьтесь со статьей "Understanding "same-site" and "same-origin" .
  • В заголовке Referer отсутствует буква R из-за первоначальной орфографической ошибки в спецификации. Заголовок Referrer-Policy и referrer в JavaScript и DOM написаны правильно.

Краткое содержание

  • Браузеры развиваются в сторону политик по умолчанию, повышающих конфиденциальность, чтобы обеспечить надежный резервный вариант, когда у веб-сайта нет установленных политик.
  • В Chrome планируется постепенно включить strict-origin-when-cross-origin в качестве политики по умолчанию в версии 85; это может повлиять на сценарии использования, зависящие от значения реферера из другого источника.
  • Это новый вариант по умолчанию, но веб-сайты по-прежнему могут выбирать политику по своему усмотрению.
  • Чтобы опробовать изменения в Chrome, включите флаг по адресу chrome://flags/#reduced-referrer-granularity . Вы также можете посмотреть эту демонстрацию , чтобы увидеть изменения в действии.
  • Помимо политики в отношении рефереров, способ обработки рефереров браузерами может измениться — поэтому следите за этим.

Что меняется и почему?

HTTP-запросы могут включать необязательный заголовок Referer , указывающий источник или URL-адрес веб-страницы, с которой был сделан запрос. Заголовок Referer-Policy определяет, какие данные доступны в заголовке Referer , а также для навигации и iframe в document.referrer целевого объекта.

Точный перечень информации, отправляемой в заголовке Referer в запросе с вашего сайта, определяется заголовком Referrer-Policy который вы устанавливаете.

Диаграмма: Реферер отправил запрос.
Политика реферера и Реферер.

Если никакая политика не задана, используется политика браузера по умолчанию. Веб-сайты часто руководствуются политикой браузера по умолчанию.

Для навигации и iframe данные, содержащиеся в заголовке Referer также можно получить через JavaScript, используя document.referrer .

До недавнего времени политика no-referrer-when-downgrade была широко распространена по умолчанию во всех браузерах. Но сейчас многие браузеры находятся на той или иной стадии перехода к более конфиденциальным настройкам по умолчанию .

Начиная с версии 85 , Chrome планирует изменить свою политику по умолчанию с no-referrer-when-downgrade на strict-origin-when-cross-origin

Это означает, что если для вашего веб-сайта не задана никакая политика, Chrome по умолчанию будет использовать strict-origin-when-cross-origin . Обратите внимание, что вы по-прежнему можете установить политику по своему выбору; это изменение повлияет только на веб-сайты, для которых политика не задана.

Что означает это изменение?

Политика strict-origin-when-cross-origin обеспечивает более высокий уровень конфиденциальности . При использовании этой политики в заголовке Referer междоменных запросов отправляется только информация об источнике .

Это предотвращает утечку конфиденциальных данных, которые могут быть доступны из других частей полного URL-адреса, таких как путь и строка запроса.

Диаграмма: Отправленный Referer в зависимости от политики, для междоменного запроса.
В зависимости от политики, для междоменных запросов отправляется Referer (а также document.referrer).

Например:

Междоменный запрос, отправленный с https://site-one.example/stuff/detail ?tag=red на https://site-two.example/…:

  • При использовании no-referrer-when-downgrade : Referer: https://site-one.example/stuff/detail ?tag=red .
  • С strict-origin-when-cross-origin : Referer: https://site-one.example/.

Что остаётся неизменным?

  • Подобно no-referrer-when-downgrade , strict-origin-when-cross-origin является безопасным : при запросе с HTTPS-источника (безопасный) к HTTP-источнику (небезопасный) отсутствует реферер (заголовок Referer и document.referrer ). Таким образом, если ваш веб-сайт использует HTTPS ( если нет, сделайте это приоритетом ), URL-адреса вашего веб-сайта не будут просачиваться в запросы без HTTPS — потому что любой в сети может их увидеть, что подвергнет ваших пользователей атакам типа «человек посередине».
  • В пределах одного источника значение заголовка Referer представляет собой полный URL-адрес.

Например: Запрос из одного источника, отправленный с https://site-one.example/stuff/detail ?tag=red на https://site-one.example/…:

  • С strict-origin-when-cross-origin : Referer: https://site-one.example/stuff/detail ?tag=red

Каковы последствия?

Судя по обсуждениям с другими браузерами и собственным экспериментам Chrome, проведенным в Chrome 84, ожидается, что видимые пользователям сбои будут минимальными .

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

Что вам нужно сделать?

Chrome планирует начать внедрение новой политики рефереров по умолчанию в версии 85 (июль 2020 года для бета-версии, август 2020 года для стабильной версии). См. статус в записи состояния Chrome .

Понять и выявить изменения

Чтобы понять, как новые настройки по умолчанию влияют на практику, вы можете посмотреть эту демонстрацию .

Вы также можете использовать эту демонстрацию, чтобы определить, какая политика применяется в запущенном вами экземпляре Chrome.

Протестируйте изменения и выясните, повлияет ли это на ваш сайт.

Вы уже можете опробовать это изменение, начиная с Chrome 81: перейдите в Chrome по chrome://flags/#reduced-referrer-granularity и включите флаг. Когда этот флаг включен, все веб-сайты без политики будут использовать новый флаг по умолчанию strict-origin-when-cross-origin .

Скриншот Chrome: как включить флаг chrome://flags/#reduced-referrer-granularity.
Включение флага.

Теперь вы можете проверить, как работает ваш веб-сайт и административная панель.

Ещё один способ выявить влияние — проверить, использует ли код вашего сайта реферер — либо через заголовок Referer входящих запросов на сервере, либо через document.referrer в JavaScript.

Некоторые функции вашего сайта могут перестать работать или вести себя по-другому, если вы используете в качестве источника рефереры запросов с другого источника (точнее, путь и/или строку запроса), И этот источник использует политику рефереров браузера по умолчанию (то есть, для него не установлена ​​никакая политика).

Если это негативно сказывается на вашем сайте, рассмотрите альтернативные варианты.

Если вы используете реферер для доступа к полному пути или строке запроса при обращении к вашему сайту, у вас есть несколько вариантов:

  • Используйте альтернативные методы и заголовки, такие как Origin и Sec-fetch-Site для защиты от CSRF-атак, ведения журналов и других целей. Ознакомьтесь с рекомендациями по использованию Referer и Referrer-Policy .
  • При необходимости вы можете согласовать с партнерами конкретную политику, которая будет прозрачна для ваших пользователей. Контроль доступа — когда веб-сайты используют Referrer для предоставления определенного доступа к своим ресурсам другим источникам — может быть именно таким случаем, хотя после изменений в Chrome источник по-прежнему будет указан в заголовке Referer (и в document.referrer ).

Обратите внимание, что большинство браузеров движутся в аналогичном направлении в отношении параметра Referrer (см. настройки браузера по умолчанию и их эволюцию в разделе Referer и Referrer-Policy: лучшие практики ).

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

Какой Referer следует отправлять в запросах, исходящих с вашего сайта, то есть какую политику следует установить для вашего сайта?

Даже с учетом изменений в Chrome, сейчас целесообразно установить явную политику, повышающую конфиденциальность, например, strict-origin-when-cross-origin или более строгую.

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

Подробную информацию о настройке политики см. в разделах «Referrer» и «Referrer-Policy: лучшие практики» .

О компании Chrome Enterprise

Корпоративная политика Chrome ForceLegacyDefaultReferrerPolicy доступна ИТ-администраторам, которые хотели бы принудительно установить предыдущую политику по умолчанию для рефереров — no-referrer-when-downgrade в корпоративных средах. Это дает предприятиям дополнительное время для тестирования и обновления своих приложений.

Данная политика будет удалена в Chrome 88.

Отправить отзыв

У вас есть отзывы или сообщения, которыми вы хотели бы поделиться? Поделитесь своим мнением о планах Chrome по выпуску новых версий или задайте свои вопросы в Твиттере @maudnals .

Выражаю огромную благодарность всем рецензентам за их вклад и отзывы, особенно Каустубхе Говинд, Дэвиду Ван Кливу, Майку Весту, Сэму Даттону, Роуэну Меревуду, Джеку и Кейси Баскес.

Ресурсы