Эта страница переведена с помощью 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; это может повлиять на варианты использования, основанные на значении реферера из другого источника.
Это новое значение по умолчанию, но веб-сайты по-прежнему могут выбирать политику по своему выбору.
Чтобы опробовать изменения в 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-адреса, таких как путь и строка запроса.

Диаграмма: Реферер отправляется в зависимости от политики для запроса между источниками. — *Реферер отправлен (и document.referrer) для запроса между источниками, в зависимости от политики.*

Например:

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

С no-referrer-when-downgrade : Реферер: https: //site-one.example/stuff/detail?tag=red .
Со strict-origin-when-cross-origin : Реферер: https://site-one.example/.

Что остается прежним?

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

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

Со strict-origin-when-cross-origin : Реферер: 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, ведения журналов и других вариантов использования. Ознакомьтесь с разделом «Referer» и «Referrer-Policy: лучшие практики» .
Вы можете согласовать с партнерами конкретную политику, если это необходимо и прозрачно для ваших пользователей. Контроль доступа — когда веб-сайты используют реферер для предоставления определенного доступа к своим ресурсам другим источникам — может быть таким случаем, хотя с изменением Chrome источник по-прежнему будет использоваться в заголовке Referer (и в document.referrer ).

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

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

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

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

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

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

О Chrome для предприятий

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

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

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

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

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