HTTP security headers: Referrer-Policy
Let’s say you’re visiting Twitter and click on a link in a tweet. When you navigate to the new website, it will know that you came from Twitter, because Twitter and other websites add something called a referrer (usually misspelled ‘referer’) header. This is how most analytics applications are able to know where your users came from. And while its great to have this information to optimize your website, it might be nice to protect your users privacy as well. The Referrer-Policy header allows several options that can help you control the amount of information you give away as a referrer.
no-referrer: Don’t set referrer information, including for pages on your own site.
no-referrer-when-downgrade: Don’t send referrer information from HTTPS pages to HTTP pages.
same-origin: Only set referrer information if the origin is the same.
origin: Set the referrer header to the origin of the request, stripping any path information.
strict-origin: Combination of
origin-when-cross-origin: Send full URL for pages in the same origin, but work like
originfor cross-origin requests.
strict-origin-when-cross-origin: Combination of
unsafe-url: Always send full URL anywhere and everywhere. Avoid this one like the plague.
You can add this to Nginx using:
add_header 'Referrer-Policy' 'strict-origin';
Which header you use should depend on your use-case. Personally, the
strict-origin policy seems best, because it is a nice combination of protecting users’ privacy and being polite to other websites by allowing them to do basic analytics. It would also prevent leaking referrer information in the event of a protocol downgrade.