Anyone who analyzed search queries before 2013 noticed that earlier, using the Referer field, it was possible to find out from which search engine and for which keyword the search was made. When going to the site, the full address of the page from which the user went was passed in the Referer header. Such an address contained a parameter with a keyword that was entered into a search engine, for example http://www.google.com.ua/search?hl=uk&q=hosting Ukraine& btnG = Google Play & meta = & aq = 8. But now we can only find out from which search engine the visitor came, since only the address of the search engine is indicated in the Referer field, for example https://www.google.com.
Every time you go from one site to another, the browser adds a Referer header with the URL of the page you are leaving. Such an address may contain information that you would not like to transfer, such as a password recovery token. For example, if you go from the site https://adm.tools/reset-password/?token=1FA5B622CDE to ukraine.com.ua, then the Referer header will be sent to ukraine.com.ua, which will contain a password reset token. To avoid such vulnerabilities, there is a Referrer-Policy header for security.
Notice - Refe headerrer, containing the name of the site from which the visitor came, contains one letter r, while the heading Referrer-Policy contains two rr.
The Referrer-Policy header supports the following values:
- no-referrer - never send a Referer header.
- same-origin - send the full URL for requests within the domain name and protocol. When you navigate through the site, a Referer with the full address will be transmitted. Useful when you are tracking visitor movement on your site.
- origin - send only the domain name, including when going to HTTP sites. If you specify strict-origin, then nothing will be transmitted when switching to the HTTP protocol.
- origin-when-cross-origin - transfer the full URL within the site, and when going to other sites, transfer only information about the domain. If you specify strict-origin-when-cross-origin, then when switching to the HTTP protocol, the Referer field will not be transmitted.
It is important to consider that if the server does not return this header, then browsers will use the value strict-origin-when-cross-origin for all requests.
The most optimal header value Referrer-policy isan origin-when-cross-origin since the transmission of Referer within the site allows tracking the movement of the visitor and does not threaten security. When you go to other sites, only the domain from which the transition was made is transferred.
There are also several meaningless values:
- no-referrer-when-downgrade - send the header whenever the protocol does not change. That is, headers are transmitted when navigating only within HTTP or only within HTTPS.
- unsafe-url - always send the full address of the site from which the transition was made. You can just not send the header, and the result will be the same.
Comparison table of headings. For example, we are on the site https://a.com/page.html and go to the specified site:
This header can be passed as the script itself, if it contains the code:
Also, this setting can be done on the side of the nginx web server:
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
You can check if sending such a header works using the tool Checking headers.
Clients of Hosting Ukraine will be able to activate this functionality in the hosting control panel in the section «Site settings».