Strict origin when cross origin что это

Referrer-Policy

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

Header type	Response header
Запрещенное имя заголовка	no

Syntax

Примечание . Исходное имя заголовка Referer является неправильным написанием слова «referrer». Referrer-Policy заголовок не разделяет эти опечатки.

Directives

Referer заголовок будет опущено: отправленные запросы не содержат никакой информации реферера.

Отправляйте источник , путь и строку запроса в Referer , когда уровень безопасности протокола остается прежним или улучшается (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Не отправляйте заголовок Referer для запросов менее безопасным адресатам (HTTPS→HTTP, HTTPS→файл).

Отправлять только источник в заголовке Referer . Например, документ на https://example.com/page.html отправит рефереру https://example.com/ .

При выполнении запроса того же источника на тот же уровень протокола (HTTP→HTTP, HTTPS→HTTPS) отправьте источник , путь и строку запроса. Отправляйте только источник для перекрестных запросов и запросов к менее безопасным местам назначения (HTTPS→HTTP).

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

Отправляйте только источник, если уровень безопасности протокола остается прежним (HTTPS→HTTPS). Не отправляйте заголовок Referer менее безопасным адресатам (HTTPS→HTTP).

Отправляйте источник, путь и строку запроса при выполнении запроса того же источника. Для запросов между источниками отправляйте источник (только), когда уровень безопасности протокола остается прежним (HTTPS→HTTPS). Не отправляйте заголовок Referer менее безопасным адресатам (HTTPS→HTTP).

Примечание. Это политика по умолчанию, если политика не указана или если предоставленное значение недействительно (см. Версию спецификации, ноябрь 2020 г. ). Раньше по умолчанию no-referrer-when-downgrade .

Отправляйте данные о происхождении,пути и строке запроса при выполнении любого запроса,независимо от уровня безопасности.

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

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

Вы также можете установить политики рефереров внутри HTML. Например, вы можете установить политику ссылающейся для всего документа с <meta> элемент с именем из referrer :

Вы можете указать атрибут referrerpolicy в элементах <a> , <area> , <img> , <iframe> , <script> или <link> , чтобы установить политики рефереров для отдельных запросов:

Кроме того , вы можете установить noreferrer ссылку отношение на , area или link элементов: a

Предупреждение: Как видно выше, noreferrer ссылки noreferrer написано без тире. Когда вы указываете политику реферера для всего документа с помощью элемента <meta> , она должна быть написана с тире: <meta name=»referrer» content=»no-referrer»> .

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

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

Fetch API

Let’s see the rest of API, to cover all its abilities.

Please note: most of these options are used rarely. You may skip this chapter and still use fetch well.

Still, it’s good to know what fetch can do, so if the need arises, you can return and read the details.

Here’s the full list of all possible fetch options with their default values (alternatives in comments):

An impressive list, right?

We fully covered method , headers and body in the chapter Fetch.

The signal option is covered in Fetch: Abort.

Now let’s explore the remaining capabilities.

referrer, referrerPolicy

These options govern how fetch sets the HTTP Referer header.

Usually that header is set automatically and contains the url of the page that made the request. In most scenarios, it’s not important at all, sometimes, for security purposes, it makes sense to remove or shorten it.

The referrer option allows to set any Referer (within the current origin) or remove it.

To send no referrer, set an empty string:

To set another url within the current origin:

The referrerPolicy option sets general rules for Referer .

Requests are split into 3 types:

Request to the same origin.
Request to another origin.
Request from HTTPS to HTTP (from safe to unsafe protocol).

Unlike the referrer option that allows to set the exact Referer value, referrerPolicy tells the browser general rules for each request type.

Possible values are described in the Referrer Policy specification:

"strict-origin-when-cross-origin" – the default value: for same-origin send the full Referer , for cross-origin send only the origin, unless it’s HTTPS→HTTP request, then send nothing.
"no-referrer-when-downgrade" – full Referer is always sent, unless we send a request from HTTPS to HTTP (to the less secure protocol).
"no-referrer" – never send Referer .
"origin" – only send the origin in Referer , not the full page URL, e.g. only http://site.com instead of http://site.com/path .
"origin-when-cross-origin" – send the full Referer to the same origin, but only the origin part for cross-origin requests (as above).
"same-origin" – send the full Referer to the same origin, but no Referer for cross-origin requests.
"strict-origin" – send only the origin, not the Referer for HTTPS→HTTP requests.
"unsafe-url" – always send the full url in Referer , even for HTTPS→HTTP requests.

Here’s a table with all combinations:

Value	To same origin	To another origin	HTTPS→HTTP
"no-referrer"	—	—	—
"no-referrer-when-downgrade"	full	full	—
"origin"	origin	origin	origin
"origin-when-cross-origin"	full	origin	origin
"same-origin"	full	—	—
"strict-origin"	origin	origin	—
"strict-origin-when-cross-origin" or "" (default)	full	origin	—
"unsafe-url"	full	full	full

Let’s say we have an admin zone with a URL structure that shouldn’t be known from outside of the site.

If we send a fetch , then by default it always sends the Referer header with the full url of our page (except when we request from HTTPS to HTTP, then no Referer ).

E.g. Referer: https://javascript.info/admin/secret/paths .

If we’d like other websites know only the origin part, not the URL-path, we can set the option:

We can put it to all fetch calls, maybe integrate into JavaScript library of our project that does all requests and uses fetch inside.

Its only difference compared to the default behavior is that for requests to another origin fetch sends only the origin part of the URL (e.g. https://javascript.info , without path). For requests to our origin we still get the full Referer (maybe useful for debugging purposes).

Referrer policy, described in the specification, is not just for fetch , but more global.

In particular, it’s possible to set the default policy for the whole page using the Referrer-Policy HTTP header, or per-link, with <a rel="noreferrer"> .

The mode option is a safe-guard that prevents occasional cross-origin requests:

"cors" – the default, cross-origin requests are allowed, as described in Fetch: Cross-Origin Requests,
"same-origin" – cross-origin requests are forbidden,
"no-cors" – only safe cross-origin requests are allowed.

This option may be useful when the URL for fetch comes from a 3rd-party, and we want a “power off switch” to limit cross-origin capabilities.

credentials

The credentials option specifies whether fetch should send cookies and HTTP-Authorization headers with the request.

"same-origin" – the default, don’t send for cross-origin requests,
"include" – always send, requires Access-Control-Allow-Credentials from cross-origin server in order for JavaScript to access the response, that was covered in the chapter Fetch: Cross-Origin Requests,
"omit" – never send, even for same-origin requests.

cache

By default, fetch requests make use of standard HTTP-caching. That is, it respects the Expires and Cache-Control headers, sends If-Modified-Since and so on. Just like regular HTTP-requests do.

The cache options allows to ignore HTTP-cache or fine-tune its usage:

"default" – fetch uses standard HTTP-cache rules and headers,
"no-store" – totally ignore HTTP-cache, this mode becomes the default if we set a header If-Modified-Since , If-None-Match , If-Unmodified-Since , If-Match , or If-Range ,
"reload" – don’t take the result from HTTP-cache (if any), but populate the cache with the response (if the response headers permit this action),
"no-cache" – create a conditional request if there is a cached response, and a normal request otherwise. Populate HTTP-cache with the response,
"force-cache" – use a response from HTTP-cache, even if it’s stale. If there’s no response in HTTP-cache, make a regular HTTP-request, behave normally,
"only-if-cached" – use a response from HTTP-cache, even if it’s stale. If there’s no response in HTTP-cache, then error. Only works when mode is "same-origin" .

redirect

Normally, fetch transparently follows HTTP-redirects, like 301, 302 etc.

The redirect option allows to change that:

"follow" – the default, follow HTTP-redirects,
"error" – error in case of HTTP-redirect,
"manual" – allows to process HTTP-redirects manually. In case of redirect, we’ll get a special response object, with response.type="opaqueredirect" and zeroed/empty status and most other properies.

integrity

The integrity option allows to check if the response matches the known-ahead checksum.

As described in the specification, supported hash-functions are SHA-256, SHA-384, and SHA-512, there might be others depending on the browser.

For example, we’re downloading a file, and we know that its SHA-256 checksum is “abcdef” (a real checksum is longer, of course).

We can put it in the integrity option, like this:

Then fetch will calculate SHA-256 on its own and compare it with our string. In case of a mismatch, an error is triggered.

keepalive

The keepalive option indicates that the request may “outlive” the webpage that initiated it.

For example, we gather statistics on how the current visitor uses our page (mouse clicks, page fragments he views), to analyze and improve the user experience.

When the visitor leaves our page – we’d like to save the data to our server.

We can use the window.onunload event for that:

Normally, when a document is unloaded, all associated network requests are aborted. But the keepalive option tells the browser to perform the request in the background, even after it leaves the page. So this option is essential for our request to succeed.

Name already in use

web.dev / src / site / content / ru / blog / referrer-best-practices / index.md

Go to file T
Go to line L
Copy path
Copy permalink

Open with Desktop
View raw
Copy raw contents Copy raw contents

Copy raw contents

Неожиданная утечка информации при запросах на другой источник препятствует конфиденциальности пользователей в Интернете. Здесь может помочь защитная политика реферера.
Рассмотрите возможность установки политики реферера strict-origin-when-cross-origin . Она сохраняет большую часть полезности реферера, одновременно снижая риск утечки данных при запросах на другой источник.
Не используйте рефереры для защиты от подделки межсайтовых запросов (CSRF). Вместо этого используйте токены CSRF и другие заголовки в качестве дополнительного уровня безопасности.

<% Aside %>Прежде чем мы начнем:

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

Кратко о заголовках Referer и Referrer-Policy

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

В приведенном ниже примере заголовок Referer включает полный URL-адрес страницы на сайте site-one , с которого был сделан запрос.

Заголовок Referer может присутствовать в разных типах запросов:

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

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

Значение Referer может быть полезным. Например, служба аналитики может использовать это значение, чтобы определить, что 50% посетителей на site-two.example пришли из social-network.example .

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

URL-адреса с №1 по №5 содержат личную информацию, иногда даже идентифицирующую или конфиденциальную. Незаметная утечка данных при запросах на другие источники может поставить под угрозу конфиденциальность пользователей в Интернете.

URL № 6это возможность URL. Вы не хотите, чтобы пароль попал в руки кого-либо, кроме предполагаемого пользователя. Если это произойдет, злоумышленник может завладеть учетной записью этого пользователя.

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

Какие политики доступны и чем они отличаются?

Вы можете выбрать одну из восьми политик. В зависимости от политики данные, из заголовка Referer (и document.referrer ) могут быть доступны следующие данные:

нет данных ( Referer отсутствует);
только источник;
полный URL-адрес: источник, путь и строка запроса.

Некоторые политики разработаны так, чтобы вести себя по-разному в зависимости от контекста: запрос на другой источник или в пределах текущего источника, безопасность, или и то, и другое (независимо от того, отправляется ли запрос из более безопасного протокола в менее безопасный). Это полезно для ограничения объема информации, передаваемой из разных источников, или для менее безопасных источниковпри сохранении разнообразия рефереров на вашем собственном сайте.

Вот обзор, показывающий, как политики реферера ограничивают данные URL, доступные из заголовка Referer и document.referrer :

Все политики, которые принимают во внимание схему (HTTPS или HTTP) ( strict-origin , no-referrer-when-downgrade и strict-origin-when-cross-origin ), обрабатывают запросы от источника HTTP к другому источнику HTTP одинаково как запросы от источника HTTPS к другому источнику HTTPS, даже если HTTP менее безопасен. Это потому, что для этих политик имеет значение, имеет ли место понижение уровня безопасности, то есть может ли запрос предоставить данные из зашифрованного источника в незашифрованный. HTTP → HTTP-запрос всё время не зашифрован, поэтому понижения уровня безопасности не происходит. HTTPS → HTTP-запросы, напротив, представляют собой понижение уровня безопасности.
При запросе в пределах одинакового источника схема (HTTPS или HTTP) не меняется; следовательно, понижения уровня безопасности не происходит.

Политики реферера по умолчанию в браузерах

По состоянию на июль 2020 г.

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

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

no-referrer-when-downgrade
Идут эксперименты со strict-origin-when-cross-origin

Настройка политики реферера: лучшие практики

<% Aside 'objective' %>Явно установите политику для повышения конфиденциальности, например, strict-origin-when-cross-origin (или более строгую).

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

как заголовок HTTP;
в вашем HTML-коде;
из JavaScript по запросу.

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

HTTP-заголовок и метаданные относятся к уровню страницы. Порядок приоритета при определении эффективной политики элемента:

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

Пример:

Изображение будет запрошено с политикой no-referrer-when-downgrade , в то время как все остальные запросы подресурсов с этой страницы будут следовать политике strict-origin-when-cross-origin .

Как посмотреть политику реферера?

Сайт securityheaders.com помогает определить политику, которую использует конкретный сайт или страница.

Вы также можете использовать инструменты разработчика Chrome, Edge или Firefox, чтобы увидеть политику реферера, используемую для конкретного запроса. На момент написания этой статьи Safari не показывает Referrer-Policy , но показывает отправленный заголовок Referer .

Какую политику вы должны установить для своего веб-сайта?

Резюме: явно установите политику для повышения конфиденциальности, например, strict-origin-when-cross-origin (или более строгую).

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

Политики браузеров по умолчанию либо no-referrer-when-downgrade , strict-origin-when-cross-origin , либо более строгиев зависимости от браузера и режима (конфиденциального просмотра или инкогнито). Таким образом, ваш сайт не будет вести себя предсказуемо в разных браузерах.
Браузеры принимают более строгие настройки по умолчанию, такие как strict-origin-when-cross-origin и такие механизмы, как referrer trimming для запросов на другой источник. Явный выбор политики повышения конфиденциальности до изменения стандартных настроек браузера дает вам контроль над ситуацией и помогает проводить тесты по своему усмотрению.

Почему strict-origin-when-cross-origin (или более строгая политика)?

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

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

Всё это означает, что strict-origin-when-cross-origin , как правило, является разумным выбором.

Пример: установка политики strict-origin-when-cross-origin

Или на стороне сервера, например в Express:

Что если политика strict-origin-when-cross-origin (или более строгая) не подходит для всех ваших вариантов использования?

В этом случае используйте прогрессивный подход: установите для вашего веб-сайта политику защиты, такую как strict-origin-when-cross-origin и, если необходимо, менее строгую политику для определенных запросов или элементов HTML.

Пример: политика на уровне элементов

Обратите внимание, что Safari/WebKit может ограничивать заголовок document.referrer или Referer для межсайтовых запросов. Смотрите подробности.

Пример: политика на уровне запроса

Что ещё нужно учесть?

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

<% Aside 'warning' %>Данные, которые могут показаться вам не конфиденциальными, могут быть конфиденциальными для ваших пользователей. Другой вариантваши пользователи не ждут, что данные будут незаметно передавать при запросах на другие источники.

Использование реферера из входящих запросов: лучшие практики

Что делать, если функционал вашего сайта использует URL-адрес реферера из входящих запросов?

Защитите данные пользователей

Заголовок Referer может содержать конфиденциальные, личные или идентифицирующие данные, поэтому убедитесь, что вы относитесь к ним как к таковым.

Имейте в виду, что получаемый вами заголовок Referer может измениться

Использование реферера из входящих запросов на другие источники имеет ряд ограничений:

Если у вас нет контроля над реализацией отправителя запросов, вы не можете делать предположения о заголовке Referer (и document.referrer ), который вы получаете. Отправитель запроса может в любой момент решить перейти на политику no-referrer или на более строгую политику, чем предыдущая,это означает, что вы получите меньше данных через Referer , чем раньше.
Браузеры всё чаще используют для Referrer-Policy значение по умолчанию strict-origin-when-cross-origin . Это означает, что теперь вы можете получать только источник (вместо полного URL-адреса реферера) во входящих запросах на другие источники, если сайт, который их отправляет, не имеет установленной политики.
Браузеры могут изменить способ управления Referer ; например, в будущем они могут решить всегда обрезать рефереры до источников в запросах подресурсов на другие источники, чтобы защитить конфиденциальность пользователей.
Referer (и document.referrer ) может содержать больше данных, чем вам нужно, например полный URL-адрес, когда вы хотите только узнать, поступил ли запрос из другого источника.

Возможно, вам придется рассмотреть альтернативы, если:

Важный функционал вашего сайта использует URL-адрес реферера из входящих запросов на другие источники;
И/или если ваш сайт больше не получает ту часть URL-адреса реферера, которая ему нужна в запросе на другой источник. Это происходит, когда отправитель запросов изменил свою политику или когда у них не задана политика, а политика браузера по умолчанию изменилась (как в Chrome 85).

Чтобы определить альтернативы, сначала проанализируйте, какую часть реферера вы используете.

Если вам нужен только источник ( https://site-one.example ):

Если вы используете реферер в скрипте, который имеет доступ к странице верхнего уровня, альтернативой является window.location.origin .
Если возможно, используйте такие заголовки, как Origin и Sec-Fetch-Site , они дадут Origin или ответ, поступил ли запрос из другого источника. Возможно, именно это вам и нужно.

Если вам нужны другие элементы URL (путь, параметры запроса…):

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

Если вы не можете использовать эти альтернативы:

Проверьте, можно ли изменить ваши системы таким образом, чтобы они ожидали от отправителя запроса ( site-one.example ) явного задания нужной вам информации в какой-либо конфигурации. Плюсы: более явный, более конфиденциальный для пользователей site-one.example с ориентацией на будущее. Минусы: потенциально большой объем работы с вашей стороны или со стороны пользователей вашей системы.
Проверьте, может ли сайт, который отправляет запросы, согласиться установить политику no-referrer-when-downgrade . Минусы: потенциально менее конфиденциальная политика для пользователей site-one.example ; может поддерживаться не во всех браузерах.

Защита от подделки межсайтовых запросов (CSRF)

Обратите внимание, что отправитель запроса всегда может решить не отправлять реферер, установив no-referrer (а злоумышленник может даже подделать реферер).

Используйте токены CSRF в качестве основной защиты. Для дополнительной защиты используйте SameSite, а вместо Referer заголовки, такие как Origin (доступно в запросах POST и CORS) и Sec-Fetch-Site (если доступно).

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

Если вы используете только источник, проверьте, может ли заголовок Origin применяться в качестве альтернативы. Этот заголовок может дать вам информацию для отладки более простым способом и без необходимости синтаксического анализа реферера.

Платежные сервисы могут полагаться на заголовок Referer входящих запросов для проверок безопасности.

Пользователь нажимает кнопку Купить на online-shop.example/cart/checkout .
online-shop.example перенаправляет на payment-provider.example для проведения транзакцим.
payment-provider.example проверяет Referer этого запроса на соответствие списку допустимых Referer , установленных продавцами. Если заголовок не соответствует ни одной записи в списке, payment-provider.example отклоняет запрос. Если соответствует, продолжается обработка транзакции пользователя.

Рекомендации по проверке безопасности потока платежей

Резюме: как платежный сервис вы можете использовать Referer в качестве базовой проверки против простых атак, но вам совершенно необходимо иметь другой, более надежный метод проверки.

Сам по себе заголовок Referer не является надежной основой для проверки: запрашивающий сайт, независимо от того, является ли он легитимным продавцом или нет, может установить политику no-referrer , которая сделает информацию Referer недоступной для платежного сервиса. Но просмотр Referer может помочь вам поймать наивных злоумышленников, которые не установили политику no-referrer . Поэтому вы можете решить использовать Referer в качестве первой базовой проверки. Если вы сделаете это:

Не ждите, что Referer всегда будет присутствовать; и если он присутствует, проверяйте только те данные, которые он минимально будет включать: источник. При задании списка разрешенных значений Referer убедитесь, что в него не включен путь, а только источник. Пример: допустимые значения Referer online-shop.example должны быть online-shop.example , а не online-shop.example/cart/checkout . Почему? Поскольку, ожидая либо отсутствия Referer вообще, либо значение Referer , которое является источником запрашивающего веб-сайта, вы предотвращаете непредвиденные ошибки, поскольку вы не делаете предположений о политике Referrer-Policy реферера, установленной вашим продавцом, или о поведении браузера, если у продавца нет установленной политики. И сайт, и браузер могут обрезать Referer отправленный во входящем запросе, только до источника или не отправлять Referer вообще.
Если заголовок Referer отсутствует или если он присутствует и ваша базовая проверка заголовка Referer прошла успешно: вы можете перейти к другому, более надежному методу проверки (см. ниже).

Какой метод проверки более надежен?

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

Что происходит с Referer , когда торговый сайт HTTP без политики реферера перенаправляет на платежный сервис HTTPS?

Заголовок Referer не будет отображаться в запросе к платежному сервису HTTPS, поскольку большинство браузеров по умолчанию используют strict-origin-when-cross-origin или no-referrer-when-downgrade , если для веб-сайта не задана политика. Также обратите внимание, что переход Chrome на новую политику по умолчанию не изменит этого поведения.

Если ваш веб-сайт использует HTTP, перейдите на HTTPS.

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

Чтобы узнать больше о различных методах защиты ваших пользователей, ознакомьтесь с коллекцией Safe and secure от web.dev!

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

As web developers, we should care about the privacy of our users. This article explains what the Referer header is and what information it exposes. We also learn to use the Referrer-Policy to control how many details the referer header should include. We can increase privacy and deal with some potential security issues by doing all of the above.

The Referer header

When we visit a website, it can contain a clickable link that redirects us to a different page. When we click on it, the browser might send a Referer request header to the server of the page we request. It contains the website’s address that includes the link we’ve used.

The word referer is a misspeling of the word referrer.

To observe this, let’s visit the wanago_io page on Twitter. It contains a bunch of links that lead to wanago.io.

When we click on the above, we get redirected to https://t.co/QtA0ttrRn3. The https//t.co address is a domain Twitter uses for shortening links. Let’s investigate its response:

Above, we can see that when we open https://t.co/QtA0ttrRn3, it immediately redirects us to wanago.io.

Thanks to the browser sending the referer : https : //t.co/ header when requesting wanago.io, I know that the person that visited the blog came from Twitter.

Security concerns around referer

Unfortunately, the Referer header carries some privacy and security risks. It is fine as long as the Referer information is used for logging or analytics. However, the Referer mechanism can be abused to track or steal sensitive information.

Imagine having the functionality of resetting a password. When the users request a new password, they get an email with a link such as this one:

When the users visit the above URL, they might click on a link before finalizing setting the new password. When that happens, some other site might get the full URL along with the secret token that we use to authorize changing the password.

Dealing with the security issues using Referrer-Policy

Thankfully, there are ways to control what information the browser includes in the referer header. One of them is using the Referrer-Policy header.

Even though the Referer header contains the misspelled word referrer, the Referrer-Policy is spelled correctly.

There are quite a few values to choose from when setting up the Referrer-Policy.

strict-origin-when-cross-origin

The strict — origin — when — cross — origin value is a default referrer policy. It means that a browser is free to send the origin, path, and the query string in the Referer header when making a same-origin request:

the user visits http://wanago.io/courses/api-with-nestjs/
clicks on a link leading to http://wanago.io/2020/05/11/nestjs-api-controllers-routing-module/
the request contains the referer : http : //wanago.io/courses/api-with-nestjs/ .

An important thing to realize is that the browser omits some parts of the URL when sending the Referer header, even in the above case. A good example is the fragment, which is the part of the URL after the # sign. The above is yet another consequence of using hash-based routing. Check out Comparing the HashRouter and the BrowserRouter in React applications for more.

If you want to know more about the parts of the URL that the browser leaves out when sending the Referer header, check out the documentation.

For the cross-origin requests, the browser sends only the page’s origin. The above means that the request would contain only the referer : http : //wanago.io/ value.

An important caveat is that the above would only happen if the security protocol stays the same. For example, if the user navigates from an HTTPS page to an HTTP website, the browser does not send the Referer header.

We should avoid including sensitive data in the URL. However, if we have to do that, the strict — origin — when — cross — origin setting ensures that the user won’t leak it outside of our website through the Referer header.

no-referrer

If we set up the Referrer-Policy to no — referrer , the browser does not send the Referer header.

The helmet library sets the no — referer value for the Referrer-Policy by default. If you want to know more about helmet, check out Increasing security of Express applications with the Helmet middleware.

unsafe-url

When we set the Referrer-Policy to unsafe — url , the browser sends the origin, path, and the query string regardless of the origin or the security protocol. Unfortunately, using this approach might cause a leak of private information, such as tokens.

no-referrer-when-downgrade

With the no — referrer — when — downgrade value, we send the origin, path, and the query string in the Referer header if the security protocol stays the same or improves. For example, if an HTTPS website redirects the user to an HTTP page, the browser doesn’t send the Referer header.

origin

If we set the Referrer-Policy to origin , the browser sends only the origin in the Referer header.

same-origin

When using the same — origin option, the browser sends the origin, path, and query string only for the same-origin requests.

strict-origin

With the strict — origin setting, the browser sends the origin through the Referer header when the security level stays the same.

origin-when-cross-origin

By setting the origin — when — cross — origin value, the browser sends the origin, path, and the query string through the Referer header for same-origin requests. On the other hand, the browser sends only the origin for cross-origin requests and when downgrading the security protocol.

Which option to choose?

After reading all of the above, we can conclude that the default strict — origin — when — cross — origin setting deals with most of the security concerns. However, if we want to increase the privacy of our users, we can consider setting the Referrer-Policy to no — referrer .