Referrer-Policy HTTP Header
Referrer-Policy HTTP Header
Referer is a request header that is confusing on multiple levels. First of all ‘referer’ is misspelt. (The correct spelling is ‘referrer’.) Even though this is an amusing fun fact, it also shows just how hard it is to even correct a simple mistake such as a missing ‘r’ in an HTTP header field. Just imagine how much harder it would be to correct a critical security vulnerability in a widespread protocol!
But the misspelling is not the only reason why this header is often not properly understood. Let’s take a look at how this header works.
How the Referrer-Policy Header Works
You are the owner of website A and you want your visitors to check out website B. You do this by placing a hyperlink to Website B on your homepage. If users click on the link, their browser will automatically add the Referer header to the request headers. It’s content will be the address of website A. This has the advantage that Website B can see who linked to their site just by checking the Referer header of each incoming request. The Referer header will be added to requests made for style, image, script loads, and form submissions. The request would look like this:
You might want to hide the information in the Referer header for multiple reasons, such as security and privacy
As a response header, Referrer-Policy gives you the following options to help control the Referer request header. Note how Referrer-Policy is written with a double r (rr). Arguably, this just adds to the Referer/Referrer spelling confusion even though it’s the correct way to write it.
The Referrer-Policy header can be set up in HTTP response messages as follows:
Referrer-Policy Directives
Here are all potential values the Referrer-Policy header can send.
|
Directive |
Description |
|
” ” (empty): |
This indicates that the Referrer-Policy is not set and that the directive to control referer can be set by an HTML element on the page. This can be done by utilizing tags or specifying a policy for individual HTML tags using the rel or referrerpolicy attributes. |
|
no-referrer: |
This will not add any Referer header even if the redirected page has the same origin as the host. |
|
no-referrer-when-downgrade: |
In case of a protocol downgrading (passing from a more secure protocol to a less secure one, such as HTTPS to HTTP), the Referer header will not be sent. This is the default behavior of all browsers. |
|
same-origin: |
This only sends the Referer header if the target site is of the same origin (scheme, domain, and port must match). You can read more about this in Introducing the Same-origin Policy Whitepaper. |
|
origin: |
This truncates the path portion of the URL in the Referer header. As mentioned above, the origin consists of the scheme, domain, and port. During protocol-downgrading (switching from HTTPS to HTTP), path information will be omitted and only origin data will be sent to the HTTP website within the referer. |
|
strict-origin: |
This value will ensure that the browser only sends the origin as the referrer when the protocol security level stays the same (e.g. HTTPS and HTTPS), but that it won’t send it to a website with a lower security level, such as from HTTPS to HTTP. |
|
origin-when-cross-origin: |
If the target and host websites have the same origin, the Referer header will include the full url. If the two have different origins, only scheme and domain data will be included in the Referer header. Origin data will also be sent to the requested HTTP site with the Referer header in case of protocol downgrading. |
|
strict-origin-when-cross-origin: |
Using this option, the origin in the Referer data will only be visible when the target and host website share in the same protocol security level or the target site is of a higher one. |
|
unsafe-url: |
Browsers will share the full URL in the Referer header in every request done from the host to the target website. You should note that with this option, the full URL will be shared even from secure to unsafe connections. This option opts you out of the default behavior of browsers (avoiding URL visibility in protocol downgrading) and therefore should be used with caution. |
Which Browsers Support Referrer-Policy Security Header?
Yet again, this header is not supported equally well in all modern browsers. In the image below you can see which browsers fully support Referrer-Policy and which don’t. For further information, visit the link below the image.
