There are privacy and security risks associated with the Referer HTTP header. This article describes them, and offers advice on mitigating those risks.
' HTTPREFERER ' The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTPREFERER as a feature. HTTP Referer is an optional HTTP header sent by web browsers with every request to the servers. It helps websites to find out their traffic sources, and many users prefer to block or spoof this information because of privacy issues. Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. So if your client is doing that, it is violating the standard. Then again, google IS the standard, and they can do whatever they want:-).
The referrer problem
The Referer (sic) header contains the address of a request (for example, the address of the previous web page from which a link to the currently requested page was followed, or the address of a page loading an image or other resource). This has many fairly innocent uses, including analytics, logging, or optimized caching. However, there are more problematic uses such as tracking or stealing information, or even just side effects such as inadvertently leaking sensitive information.
For example, consider a 'reset password' page with a social media link in a footer. If the link was followed, depending on how information was shared the social media site may receive the reset password URL and may still be able to use the shared information, potentially compromising a user's security.
Http_referer Script
By the same logic, an image from a third party site embedded in your page could result in sensitive information being leaked to the third party. Even if security is not compromised, the information may not be something the user wants shared.
How can we fix this?
Http_referer Apache
Much of this risk can be mitigated by sensible design of applications. A sensible application would remove such risks by making single-use password reset URLs, or combining them with a unique user token. The risk can also be reduced by transmitting sensitive data in more secure ways.
You should use POST rather than GET wherever possible, to avoid passing sensitive data to other locations via URLs.
Http_referer Header
You should always use HTTPS for your sites. This has many security advantages, including the fact that HTTPS sites will never transmit referrer information to non-HTTPS sites. This advice is less relevant now that most of the web is using HTTPS, but it is still a worthy consideration.
In addition, you should consider removing any third party content (e.g. social networking widgets embedded in </code>) from secure areas of your website, like password reset pages, payment forms, login areas, etc.</p><h3 id='url-referer-header'>Url Referer Header</h3><p>You can also mitigate such risks using:</p><ul><li>The <code>Referrer-Policy</code> header on your server to control what information is sent through the <code>Referer</code> header. For example, a directive of <code>no-referrer</code> would omit the Referer header entirely.</li><li>The <code>referrerpolicy</code> attribute on HTML elements that are in danger of leaking such information (such as <code><img></code> and <code><a></code>). This can for example be set to <code>no-referrer</code> to stop the <code>Referer</code> header being sent altogether.</li><li>The <code>rel</code> attribute set to <code>noreferrer</code> on HTML elements that are in danger of leaking such information (such as <code><img></code> and <code><a></code>). See Link types and search for <code>noreferrer</code> for more information.</li><li>The Exit page technique.</li></ul><p>Security-conscious server-side frameworks tend to have built in mitigations for such problems, for example:</p><h3 id='httpreferer-php'>Http_referer Php</h3><ul><li>Security in Django (especially see Cross site request forgery (CSRF) protection).</li><li>helmetjs referrer-policy — middleware for setting Referrer-Policy in Node.js/Express apps (see also helmetjs for more security provisions).</li></ul><h2>Policy and requirements</h2><p>It would make sense to write a set of security and privacy requirements for your project team(s) that specify usage of such features to mitigate the associated risks. You should enlist the help of a web security expert to write these requirements, and consider both user needs and welfare, as well as other issues like policy and regulation enforced by legislation such as the EU General Data Protection Regulation (GDPR).</p><h2>See also</h2><br><br><br><br>
