Referrer Policy (Русская версия)

Редакция от 25 мая 2022 г.

Резюме

В этом документе описывается, как автор может установить политику рефёрера (referrer policy) для создаваемых документов, а также влияние такой политики на HTTP-заголовок «Referer« для исходящих запросов и переходов.

Статус этого документа

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

Изменения в этом документе можно отслеживать по адресу https://github.com/w3c/webappsec.

(Заархивированный) общедоступный список рассылки public-webappsec@w3.org (смотри инструкции) предпочтительнее для обсуждения этой спецификации. При отправке электронного письма, пожалуйста, поместите текст «REFERRER-POLICY» в тему, желательно так: «[РЕФЕРАТОРНАЯ ПОЛИТИКА]… краткое изложение комментария…»

Этот документ был подготовлен Рабочей группой по безопасности веб-приложений.

Этот документ был подготовлен группой, действующей в соответствии с Патентной политикой W3C. W3C ведет публичный список любых раскрытий патентов, сделанных в связи с результатами работы группы; эта страница также включает инструкции по раскрытию патента. Лицо, которое фактически знает о патенте, который, по его мнению, содержит существенные пункты формулы (-ий), должен раскрыть информацию в соответствии с разделом 6 Патентной политики W3C.

Этот документ регулируется Документом процесса W3C от 15 сентября 2020 года.

1. Введение

Этот раздел не является нормативным.

Запросы, сделанные из документа, и для перехода от этого документа, связаны с заголовком Referer. Хотя заголовок может быть подавлен для ссылок с типом ссылки noreferrer, авторы могут захотеть более непосредственно управлять заголовком Referer по ряду причин:

1.1. Конфиденциальность

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

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

1.2. Безопасность

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

В качестве альтернативы веб-приложение может использовать URL-адреса, которые сами по себе предоставляют определенные возможности. Управление рефёрером может помочь предотвратить утечку URL-адресов этих возможностей через заголовки рефёрера. [CAPABILITY-URLS]

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

1.3. Трекбэк

Блог, размещённый по протоколу HTTPS, может захотеть создать ссылку на блог, размещённый по протоколу HTTP, и получить обратные ссылки.

2. Ключевые понятия и терминология

referrer policy (политика рефёрера)

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

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

same-origin-referrer request (запрос того же источника перехода)

Запрос Request является запросом того же источника-рефёрера, если источник URL-адреса рефёрера запроса и источник текущего URL-адреса запроса совпадают.

cross-origin-referrer request (запрос с переходом от другого источника)

Request является запросом с переходом от одного источника к другому, если он НЕ является запросом от одного источника.

3. Политика рефёрера

Политика рефёрера — это пустая строка, «no-referrer», «no-referrer-when-downgrade», «same-origin», «origin», «strict-origin», «origin-when-cross-origin», «strict-origin-when-cross-origin» или «unsafe-url».

enum ReferrerPolicy {
  "",
  "no-referrer",
  "no-referrer-when-downgrade",
  "same-origin",
  "origin",
  "strict-origin",
  "origin-when-cross-origin",
  "strict-origin-when-cross-origin",
  "unsafe-url"
};

Каждая возможная политика рефёрера объясняется ниже. Подробный алгоритм оценки их эффекта приведен в разделах §5 «Интеграция с выборкой» и §8 «Алгоритмы».

Политика рефёрера по умолчанию (default referrer policy) —  «strict-origin-when-cross-origin« (строгое происхождение при перекрестном происхождении).

3.1. «no-referrer»

Самая простая политика — «no-referrer», которая указывает, что никакая информация о реферере не должна отправляться вместе с запросами к какому-либо источнику. Заголовок Referer будет полностью опущен.

3.2. «no-referrer-when-downgrade»

Политика «no-referrer-when-downgrade« отправляет полный URL-адрес рефёрера запроса, очищенный для использования в качестве рефёрера для запросов:

• чей URL-адрес рефёрера и текущий URL-адрес являются потенциально заслуживающими доверия URL-адресами
• чей URL-адрес рефёрера НЕ является потенциально надёжным URL-адресами.

Запросы, для которых URL-адрес рефёрера является потенциально заслуживающим доверия URL-адресом, а текущий URL-адрес НЕ является потенциально заслуживающим доверия URL-адресом, с другой стороны, не будут содержать информации о рефёрере. HTTP-заголовок Referer не будет отправлен.

3.3. «same-origin»

Политика «same-origin« (того же источника) указывает, что полный URL-адрес рефёрера запроса отправляется в качестве информации о рефёрере при выполнении запросов с одним и тем же источником-рефёрером.

С другой стороны, запросы с перекрёстным источником перехода не будут содержать информации о рефёрере (источнике перехода). HTTP-заголовок Referer не будет отправлен.

3.4. «origin»

Политика «origin» указывает, что только ASCII-сериализация URL-адреса реферера запроса отправляется в качестве информации реферера при выполнении как запросов с одинаковым источником, так и запросов с перекрестным источником.

3.5. «strict-origin»

Политика «strict-origin» отправляет ASCII-сериализацию происхождения URL-адреса реферера для запросов:

• чей URL-адрес реферера и текущий URL-адрес являются потенциально заслуживающими доверия URL-адресами
• чей URL-адрес реферера не является потенциально надежным.

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

3.6. «origin-when-cross-origin»

Политика «origin-when-cross-origin» указывает, что полный URL-адрес реферера запроса отправляется как информация о реферере при выполнении запросов с тем же источником-реферер, и только ASCII-сериализация источника URL-адреса реферера отправляется как информация о реферере при выполнении запросы с переходом от другого источника.

3.7. «strict-origin-when-cross-origin»

Политика «strict-origin-when-cross-origin» указывает, что полный URL-адрес реферера запроса отправляется как информация о рефёрере при выполнении запросов с тем же источником-рефёрер, и только сериализация ASCII источника URL-адреса рефёрера запроса при создании перекрестного источника. -рефёррера запросы:

• чей URL-адрес рефёрера и текущий URL-адрес являются потенциально заслуживающими доверия URL-адресами
• чей URL-адрес рефёрера НЕ является потенциально надежным.

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

Эта политика используется пользовательским агентом по умолчанию и будет применяться, если не указано иное.

3.8. «unsafe-url»

Политика «unsafe-url» указывает, что полный URL-адрес реферера отправляется как для запросов с одинаковым источником, так и для запросов с перекрестным источником.

3.9. Пустая строка

Пустая строка «» соответствует отсутствию политики рефёрера, вызывая откат к политике рефёрера, определенной в другом месте, или в случае, когда такая политика более высокого уровня недоступна, откат к политике рефёрера по умолчанию. Это происходит, например, в основном алгоритме выборки Fetch.

4. Доставка политики рефёрера

Политика рефёрера запроса доставляется одним из пяти способов:

1. Через HTTP-заголовок Referrer-Policy (определенный в §4.1 Доставка через заголовок Referrer-Policy).
2. Через метаэлемент с именем рефёрера.
3. Через атрибут содержимого referrerpolicy в элементе a, area, img, iframe, link или script.
4. Через отношение ссылки noreferrer в элементе a или area.
5. Неявно, через наследование.

4.1. Доставка через заголовок Referrer-Policy

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

Синтаксис имени и значения заголовка описывается следующей грамматикой ABNF. ABNF определен в [RFC5234], а используемое ниже расширение #rule ABNF определено в разделе 7 [RFC7230].

"Referrer-Policy:" 1#(policy-token / extension-token)

policy-token = "no-referrer" / "no-referrer-when-downgrade" / "strict-origin" / "strict-origin-when-cross-origin" / "same-origin" / "origin" / "origin-when-cross-origin" / "unsafe-url"
extension-token = 1*( ALPHA / "-" )

§5 Интеграция с Fetch и §6 Интеграция с HTML описывают, как обрабатывается заголовок Referrer-Policy.

4.1.1. Использование

Этот раздел не является нормативным.

Защищённый ресурс может предотвратить утечку рефёрера, указав no-referrer в качестве значения его заголовка Referrer-Policy:

Referrer-Policy: no-referrer

Это приведет к тому, что все запросы, сделанные из контекста защищенного ресурса, будут иметь пустой заголовок Referer [sic].

4.2. Доставка через <meta>

Этот раздел не является нормативным.

Стандарт HTML определяет ключевое слово рефёрера для элемента <meta>, который позволяет установить политику рефёрера через разметку.

4.3. Доставка через атрибут содержимого referrerpolicy

Этот раздел не является нормативным.

Стандарт HTML определяет концепцию атрибутов политики рефёрера, которая применяется к нескольким ее элементам, например:

4.4. Наследование политики рефёрера

Этот раздел не является нормативным.

Политика рефёрера наследуется в соответствии с механизмом наследования контейнеров политик, как определено в HTML.

5. Интеграция с Fetch

Этот раздел не является нормативным.

Спецификация Fetch обращается к §8.2 Установить политику рефёрера запроса при перенаправлении перед шагом 13 выборки с перенаправлением HTTP, чтобы можно было обновить политику рефёрера запроса перед выполнением перенаправления.

Спецификация Fetch обращается к §8.3 Определить рефёрер запроса как шаг 8 основного алгоритма выборки и использует результат для установки свойства рефёрера запроса. Fetch отвечает за сериализацию предоставленного URL и установку заголовка Referer по запросу.

6. Интеграция с HTML

Этот раздел не является нормативным.

Стандарт HTML определяет политику рефёрера любого ответа, полученного во время навигации или во время выполнения работника, и использует результат для установки политики рефёрера контейнера политик полученного документа или контейнера политик WorkerGlobalScope.

7. Интеграция с CSS

Стандарт CSS не определяет, как он выбирает ресурсы, на которые есть ссылки из таблиц стилей. Однако реализации должны быть уверены, что установили связанные с реферером свойства любых запросов, инициированных таблицами стилей, следующим образом:

1. Если за запрос отвечает таблица стилей CSS, а ее расположение не равно нулю, установите для источника ссылки ее расположение, а для политики ссылки — ее политику ссылки.

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

3. В противном случае блок объявления CSS, созданный средством внедрения, отвечает за запрос — либо в результате синтаксического анализа атрибута стиля элемента, либо для реализации презентационной подсказки для элемента. Мы предполагаем, что в этом случае узел-владелец блока объявления CSS указывает на этот элемент, и устанавливаем реферер на URL-адрес документа узла узла-владельца блока, а политику реферера — на политику реферера контейнера политики документа узла узла-владельца блока.

8. Алгоритмы

8.1. Анализировать политику рефёрера из заголовка Referrer-Policy

В ответ на ответ следующие шаги возвращают политику реферера в соответствии с заголовком ответа «Referrer-Policy»:

1. Пусть токены политики policy-tokens будут результатом извлечения значений списка заголовков из «Referrer-Policy» и списка заголовков ответа response.

2. Пусть политика policy будет пустой строкой.

3. Для каждого токена token в токенах политики policy-tokens, если токен token является политикой рефёрера и токен token не является пустой строкой, тогда установите политику policy в токен token .

4. Вернуть policy.

8.2. Установить политику рефёрера запроса request при перенаправлении

Учитывая запрос request и ответ actualResponse, этот алгоритм обновляет политику рефёрера запроса request в соответствии с заголовком Referrer-Policy (если есть) в actualResponse.

1. Пусть политика policy будет результатом выполнения §8.1. Разобрать политику реферера из заголовка Referrer-Policy на фактическом ответе actualResponse.

2. Если политика policy не является пустой строкой, тогда установите политику рефёрера запроса request на policy.

8.3. Определить рефёрер запроса

Учитывая запрос запроса, мы можем определить правильную информацию о реферере для отправки, изучив его политику реферера, как подробно описано в следующих шагах, которые не возвращают реферера или URL:

1. Пусть политика будет политикой реферера запроса.

2. Пусть среда будет клиентом запроса.

3. Включить реферер запроса:

«клиент»

1. Если глобальный объект среды является объектом Window, тогда

1. Пусть документ будет связанным документом глобального объекта среды.

2. Если источник документа непрозрачный, реферер не возвращается.

3. Хотя документ является документом srcdoc iframe, пусть документ будет документом узла контейнера контекста просмотра контекста просмотра.

4. Пусть referrerSource будет URL-адресом документа.

2. В противном случае пусть referrerSource будет URL-адресом создания среды.

URL

Пусть referrerSource будет рефёрером запроса.

4. Пусть URL-адрес рефёрера запроса будет результатом удаления источника реферера для использования в качестве реферера.

5. Пусть referrerOrigin будет результатом удаления источника referrerSource для использования в качестве рефёрера с установленным флагом origin-only значением true.

6. Если результатом сериализации URL-адреса рефёрера является строка, длина которой превышает 4096, установите для URL-адреса рефёрера значение referrerOrigin.

7. Пользовательский агент МОЖЕТ изменить URL-адрес реферера или реферерOrigin на этом этапе, чтобы обеспечить соблюдение произвольных правил политики в интересах минимизации утечки данных. Например, пользовательский агент может вырезать URL-адрес до источника, изменить его хост, заменить его пустой строкой и т. д.

8. Выполните инструкции, соответствующие значению политики:

Примечание.

Если политика рефёрера запроса представляет собой пустую строку, Fetch не будет вызывать этот алгоритм.

«no-referrer«

Вернуть «no referrer»

«origin«

Вернуть referrerOrigin

«unsafe-url«

Вернуть URL-адрес рефёрера.

«strict-origin«

1. Если URL-адрес реферера является потенциально заслуживающим доверия URL-адресом, а текущий URL-адрес запроса не является потенциально заслуживающим доверия URL-адресом, то реферер не возвращается.

2. Вернуть referrerOrigin.

«strict-origin-when-cross-origin«

1. Если источник URL-адреса реферера и источник текущего URL-адреса запроса совпадают, тогда верните URL-адрес реферера.

2. Если URL-адрес реферера является потенциально заслуживающим доверия URL-адресом, а текущий URL-адрес запроса не является потенциально заслуживающим доверия URL-адресом, то вернуть «no referrer».

3. Вернуть referrerOrigin.

«same-origin« («того же происхождения»)

1. Если источник URL-адреса реферера и источник текущего URL-адреса запроса совпадают, тогда верните URL-адрес реферера.

2. Вернуть «no referrer»

«origin-when-cross-origin« («происхождение-при-перекрестном происхождении»)

1. Если источник URL-адреса реферера и источник текущего URL-адреса запроса совпадают, тогда верните URL-адрес реферера.

2. Вернуть referrerOrigin.

«no-referrer-when-downgrade« («без перехода на более раннюю версию»)

1. Если URL-адрес реферера является потенциально заслуживающим доверия URL-адресом, а текущий URL-адрес запроса не является потенциально заслуживающим доверия URL-адресом, то реферер не возвращается.

2. Вернуть URL-адрес реферера.

8.4. Убрать URL-адрес url для использования в качестве рефёрера

Определенные части URL-адресов не должны включаться при отправке URL-адреса в качестве значения заголовка «Referer«: фрагмент URL-адреса, имя пользователя и компоненты пароля должны быть удалены из URL-адреса перед его отправкой.

Этот алгоритм принимает «флаг только источника» (origin-only flag), который по умолчанию имеет значение false.

Если установлено значение true, алгоритм дополнительно удалит компоненты пути и запроса URL-адреса, оставив только схему, хост и порт.

1. Если url равен null, вернуть «no referrer».

2. Если схема url является локальной схемой, тогда вернуть «no referrer».

3. Установите имя пользователя url на пустую строку.

4. Установите пароль url на пустую строку.

5. Установите фрагмент url значение null.

6. Если флаг origin-only flag является true, то:

1. Установите путь url значение «пустая строка».

2. Установите запрос url значение null.

7. Вернуть url.

9. Вопросы конфиденциальности

9.1. Пользовательские элементы управления

Ничто в этой спецификации не должно быть истолковано как препятствие тому, чтобы пользовательские агенты предлагали пользователям варианты, которые могут изменить информацию, отправляемую через заголовок Referer. Например, пользовательские агенты МОГУТ позволять пользователям полностью подавлять заголовок реферера, независимо от активной политики реферера на странице.

10. Соображения безопасности

10.1. Утечка информации

Политики реферера «origin», «origin-when-cross-origin» и «unsafe-url» могут пропускать источник и URL-адрес защищенного сайта соответственно через небезопасный транспорт.

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

Авторы, желающие убедиться, что они не утекают больше информации, чем политика по умолчанию, должны вместо этого использовать состояния политики «то же происхождение», «строгое происхождение» или «без реферера».

10.2. Переход на менее строгие правила

Спецификация не запрещает переход к менее строгим политикам, например, с «no-referrer» на «unsafe-url».

С одной стороны, неясно, какая политика более строгая для всех возможных пар политик: в то время как «no-referrer-when-downgrade» не приведет к утечке информации по небезопасному транспорту, а «origin» будет, последнее раскрывает меньше информация по кросс-исходной навигации.

С другой стороны, возможность установки менее строгих политик позволяет авторам определять безопасные откаты, как описано в §11.1 Неизвестные значения политики.

11. Соображения по поводу авторских прав

11.1. Неизвестные значения политики

Как описано в §8.1 Анализ политики реферера из заголовка Referrer-Policy и в алгоритме мета-реферера, неизвестные значения политики будут игнорироваться, и когда несколько источников определяют политику реферера, будет использоваться значение самого последнего. Это позволяет использовать новые значения политики.

Referrer-Policy: no-referrer
Referrer-Policy: unsafe-url

Referrer-Policy: no-referrer,unsafe-url

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

12. Благодарности

Эта спецификация в значительной степени основана на справочном документе «Мета» авторов Адама Барта (Adam Barth) и Йохена Эйзингера (Jochen Eisinger).

Франсуа Мариер (Francois Marier) разработал политики «одинакового происхождения» (same-origin), «строгого происхождения» (strict-origin) и «строгого происхождения при пересечении происхождения» (strict-origin-when-cross-origin).

Соответствие

Условные обозначения в документе

Требования соответствия выражаются комбинацией описательных утверждений и терминологии RFC 2119. Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ОБЯЗАТЕЛЬНО», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в нормативных частях. этого документа следует интерпретировать, как описано в RFC 2119. Однако для удобства чтения эти слова не отображаются в этой спецификации всеми прописными буквами.

Весь текст данной спецификации является нормативным, за исключением разделов, явно отмеченных как ненормативные, примеров и примечаний. [RFC2119]

Примеры в этой спецификации вводятся словами «например» или выделяются отдельно от нормативного текста с помощью class = «example», например:

Информационные заметки начинаются со слова «Примечание» и выделяются отдельно от нормативного текста с помощью class = «note», например:

Соответствующие алгоритмы

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

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

Индекс

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

• «», in § 3
• cross-origin-referrer request, in § 2
• default referrer policy, in § 3
• Determine request’s Referrer, in § 8.2
• extension-token, in § 4.1
• «no-referrer»
  • definition of, in § 3
  • enum-value for ReferrerPolicy, in § 3
• «no-referrer-when-downgrade»
  • definition of, in § 3.1
  • enum-value for ReferrerPolicy, in § 3
• «origin»
  • definition of, in § 3.3
  • enum-value for ReferrerPolicy, in § 3
• origin-only flag, in § 8.4
• «origin-when-cross-origin»
  • definition of, in § 3.5
  • enum-value for ReferrerPolicy, in § 3
• policy-token, in § 4.1
• referrer policy
  • definition of, in § 3
  • dfn for CSSStyleSheet, in § 7
• Referrer-Policy, in § 4.1
• ReferrerPolicy, in § 3
• referrer-policy header, in § 4.1
• referrerURL, in § 8.3
• «same-origin»
  • definition of, in § 3.2
  • enum-value for ReferrerPolicy, in § 3
• same-origin-referrer request, in § 2
• Set request’s referrer policy on redirect, in § 8.1
• «strict-origin»
  • definition of, in § 3.4
  • enum-value for ReferrerPolicy, in § 3
• «strict-origin-when-cross-origin»
  • definition of, in § 3.6
  • enum-value for ReferrerPolicy, in § 3
• The empty string, in § 3.8
• «unsafe-url»
  • definition of, in § 3.7
  • enum-value for ReferrerPolicy, in § 3

Термины определены ссылкой

• [cssom-1] defines the following terms:
  • css declaration block
  • css style sheet
  • location
  • owner node (for CSSStyleSheet)
• [DOM] defines the following terms:
  • node document
  • origin
  • url
• [FETCH] defines the following terms:
  • Request
  • client
  • current url
  • extracting header list values
  • fetch
  • header list
  • local scheme
  • referrer
  • referrer policy
  • request
  • response
• [HTML] defines the following terms:
  • Document
  • Window
  • WorkerGlobalScope
  • a
  • an iframe srcdoc document
  • area
  • ascii serialization of an origin
  • associated document
  • browsing context (for Document)
  • browsing context container
  • creation url
  • document referrer policy
  • environment settings object
  • fragment
  • global object
  • iframe
  • img
  • link
  • meta
  • name
  • navigation
  • noreferrer
  • opaque origin
  • origin
  • policy container (for WorkerGlobalScope)
  • presentational hints
  • referrer
  • referrer policy
  • referrer policy attribute
  • referrerpolicy
  • running a worker
  • same origin
  • script
  • style attribute
• [INFRA] defines the following terms:
  • length
• [RFC5234] defines the following terms:
  • alpha
• [rfc7231] defines the following terms:
  • referer
• [secure-contexts] defines the following terms:
  • potentially trustworthy url
• [URL] defines the following terms:
  • host
  • origin
  • password
  • path
  • query
  • scheme
  • url
  • url serializer
  • username

Использованная литература

Нормативные ссылки

[CSSOM-1]Daniel Glazman; Emilio Cobos Álvarez. CSS Object Model (CSSOM). 26 August 2021. WD. URL: https://www.w3.org/TR/cssom-1/

[DOM]Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/

[FETCH]Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/

[HTML]Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/

[INFRA]Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/

[RFC2119]S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119

[RFC5234]D. Crocker, Ed.; P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234

[RFC7230]R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html

[RFC7231]R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html

[SECURE-CONTEXTS]Mike West. Secure Contexts. 18 September 2021. CR. URL: https://www.w3.org/TR/secure-contexts/

[URL]Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/

Информационные ссылки

[CAPABILITY-URLS]Jeni Tennison. Good Practices for Capability URLs. 18 February 2014. WD. URL: https://www.w3.org/TR/capability-urls/

IDL указатель

Указатель проблем

Для этого необходимо, чтобы таблицы стилей CSS обрабатывали заголовки «Referrer-Policy» и сохраняли политику рефёрера так же, как это делают Документы.