Эта страница переведена с помощью Cloud Translation API.

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

Maud Nalpas

Прежде чем мы начнем:

Если вы не уверены в разнице между «сайтом» и «источником», ознакомьтесь со статьей Понимание терминов «один и тот же сайт» и «один и тот же источник» .
В заголовке Referer отсутствует буква R из-за изначальной опечатки в спецификации. Заголовок Referrer-Policy и referrer в JavaScript и DOM написаны правильно.

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

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

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

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

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

Диаграмма: Реферер отправил запрос. — *Referrer-Policy и Referer.*

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

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

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

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

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

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

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

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

Диаграмма: Отправка реферера в зависимости от политики для запроса между источниками. — *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://flags/#reduced-referrer-granularity в Chrome и включите этот флаг. После включения этого флага все сайты без политики будут использовать новое strict-origin-when-cross-origin .

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

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

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

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

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

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

Используйте альтернативные методы и заголовки, такие как Origin и Sec-fetch-Site , для защиты от CSRF-атак, ведения журналов и других целей. Ознакомьтесь с разделом «Реферер и политика реферера: рекомендации» .
Вы можете согласовать с партнёрами определённую политику, если это необходимо и прозрачно для ваших пользователей. Контроль доступа — когда реферер используется веб-сайтами для предоставления определённого доступа к своим ресурсам другим источникам — может быть одним из таких случаев, хотя с изменениями в Chrome источник по-прежнему будет указываться в заголовке Referer (и в document.referrer ).

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

Реализуйте на своем сайте четкую политику конфиденциальности.

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

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

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

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

О Chrome Enterprise

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

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

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

Хотите оставить отзыв или сообщить о чём-то? Поделитесь своим мнением о намерении Chrome выпустить релиз или напишите свои вопросы в Твиттере @maudnals .

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