User:Apking/Web Security Guidelines: Difference between revisions

| Improves privacy for users, prevents leaking of internal URLs via Referer

When a user navigates to a site via a hyperlink or a webpage includes an external resource, browsers inform these sites of the origin of the requests through the use of the HTTP <tt>Referer</tt> (sic) header. Although this can be useful for a variety of purposes, it can also place the privacy of users at risk.  HTTP Referrer Policy is an HTTP header and &lt;meta&gt; tag that allows sites to have fine-grained control over how browsers use the HTTP <tt>Referer</tt> header. For example, if a page at https://example.com/page.html contains <tt>&lt;img src="https://not.example.com/image.jpg"&gt;</tt>, then the browser will send a request like this:

To reduce the exposure of this information, it is recommended that websites use HTTP Referrer Policy to either eliminate the Referer header entirely, or reduce the amount of information that it contains.

<tt>no-referrer</tt>: never send the Referrer header

<tt>same-origin</tt>: send referrer, but only on requests to the same origin

<tt>strict-origin</tt>: send referrer to all origins, but only the URL sans path (e.g. https://example.com/)

<tt>strict-origin-when-cross-origin</tt>: send full referrer on same origin, URL sans path on foreign origin

There are many additional options for referrer policies, but they do not protect user privacy in the same way as the options above. <tt>no-referrer-when-downgrade</tt> is the default behavior for all current browsers, and can be used when sites are concerned about breaking existing systems that rely on the full Referrer header for their operation.

Please note that support for Referrer Policy is still in its infancy. Chrome currently only supports <tt>no-referrer</tt> from the options above, and Firefox awaits full support with Firefox 52.