None

HTTP Referrer Policy header


How to control your http references on your web pages like a pro.

By Kostas Koutsogiannopoulos

Introduction

This is a typical line from access logs of a web server:

XXX.XXX.XXX.XXX - - [07/Feb/2019:06:48:29 +0200] "GET /en/blog/2016/05/25/websphere-profile-management-ansible/ HTTP/2.0" 200 29324 "https://www.google.com/" "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0"

 

We will deal with the "referrer" part which in this case is "https://www.google.com/".

You may wonder how your web server knows the website that is referring to your page.

Basic terms

  • User agent: The program that is rendering the web pages - most likely a browser like mozilla firefox
  • Referrer: The web page that is referring to another web page
  • url: Uniform Resource Locator like https://www.epilis.gr/en/blog/2019/02/20/http-referrer-policy-header/
  • origin: The protocol along with the host name part of the url like https://www.epilis.gr
  • HTTP: Hypertext Transfer Protocol. The protocol that is used for transmitting requests/responds between web server and user agent
  • HTTP headers: Components of the header section of request and response messages in the HTTP. Headers define the operating parameters of an HTTP transaction

The referral mechanics

Based on the mentioned above access.log line, we have a user agent described by the string "Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0".

So there is a user who is browsing https://www.google.com/<something> page.

In this page there is probably an html link like this:

<a href="https://www.epilis.gr/en/blog/2016/05/25/websphere-profile-management-ansible/">Some link description</a>

User clicks(or touches) on this link triggering a "GET /en/blog/2016/05/25/websphere-profile-management-ansible/ HTTP/2.0" request to our web server.
If we analyze the request we will find out that the browser set some HTTP headers and one of them is:

Referrer: https://www.google.com/

 

You can check this for your own requests from your browser. For example in firefox menu:

Web Developer > Network

...you can click on any request/response and check the headers:

So our web server knows (and logs) the referrer of this request. We can use this information to make conclusions about where our users come from.
Of course this information is sensitive for the users, and we need a mechanism to control how browsers (or user agents in general) should report our referrals.

How to control your own referrals

Just like the "Referrer" header we mentioned above, there are some other headers under the family name "security headers" that a user agent can use to make decisions on its user's security. The one that we need about referrals is "referrer-policy". Using this header we can instruct the agents to:

  • Report the full url of the referrer's page (eg. https://www.example.com/page1/)
  • Report only the domain name of the referrer's page (eg. https://www.example.com/)
  • Report nothing at all

There is also the capability to follow different policy depending on:

  • Referring from a secure page to another secure page (https to https)
  • Referring from a secure page to a non secure page (https to http)
  • Referring to another page of the same origin (https://www.example.com/page1 to https://www.example.com/page2)
  • Referring to another page of another origin (https://www.example1.com/page1 to https://www.example2.com/page2)

This is essential because user's sensitive information is in danger when the other web page is less secure than the page that is doing the reference.

So for the referrer-policy header there are the following options:

  • no-referrer: Report nothing in any case
  • no-referrer-when-downgrade: This is the default behaviour. User agent is reporting the full url only when there is no change on security and nothing when security is downgraded
  • origin: Report only the origin in all cases
  • origin-when-cross-origin: Report only the origin when we refer to another origin and full url when we refer another page of the same origin
  • same-origin: Report only the origin when we refer on the same origin and nothing in other cases
  • strict-origin: Report only origin when security stays the same and nothing when security is downgraded
  • strict-origin-when-cross-origin: Report full url when referring to the same origin, only origin when referring to another origin and nothing when security is downgraded
  • unsafe-url: Report full url in any case (the least safe option)

Implementation

We can set the referrer-policy header with the policy of our choice using the following options:

Per link, using the referrerpolicy attribute on <a>, <area>, <img>, <iframe>, or <link> elements (we can also set the referrerpolicy attribute via CSS):

<a href="http://example.com" referrerpolicy="no-referrer-when-downgrade">

 

Per page, using HTML "meta" header.

For example:

<meta name="referrer" content="no-referrer-when-downgrade">

 

Per web site (virtual host) using our web server to set the referrer-policy header.

For example on nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin";

...on any of http, server, location, if in location configuration block.

 

On apache with directives provided by mod_headers module:

Header set Referrer-Policy "no-referrer-when-downgrade"

Testing

You can easily test online your Referrer-Policy header and security headers in general, using this site:

https://securityheaders.com/

 


View epilis's profile on LinkedIn Visit us on facebook X epilis rss feed: Latest articles