Scribd
Upload
22 views3 pages

Referer Header Privacy and Security Concerns - Security On The Web MDN

The document discusses the privacy and security risks associated with the Referer HTTP header, highlighting potential issues like information leakage and tracking. It offers mitigation strategies, including using POST requests, HTTPS, and various HTML attributes to control Referer information. Additionally, it suggests developing security requirements for projects and consulting web security experts to address these risks effectively.

Uploaded by

480
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
22 views3 pages

Referer Header Privacy and Security Concerns - Security On The Web MDN

The document discusses the privacy and security risks associated with the Referer HTTP header, highlighting potential issues like information leakage and tracking. It offers mitigation strategies, including using POST requests, HTTPS, and various HTML attributes to control Referer information. Additionally, it suggests developing security requirements for projects and consulting web security experts to address these risks effectively.

Uploaded by

480
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

There are privacy and security risks associated with the Referer HTTP header.

This
article describes them, and offers advice on mitigating those risks.

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.

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.

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.
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 <iframe> ) from secure areas of your website, like
password reset pages, payment forms, login areas, etc.

You can also mitigate such risks using:

• The Referrer-Policy header on your server to control what information is sent


through the Referer header. For example, a directive of no-referrer would omit the
Referer header entirely.

• The referrerpolicy attribute on HTML elements that are in danger of leaking such
information (such as <img> and <a> ). This can for example be set to no-referrer to
stop the Referer header being sent altogether.

• The rel attribute set to noreferrer on HTML elements that are in danger of leaking
such information (such as <form> and <a> ).

• A <meta> element with a name of referrer and the content set to no-referrer to
disable the Referer header for the whole document. See Referrer-Policy Integration
with HTML.

• The Exit page technique.

Security-conscious server-side frameworks tend to have built in mitigations for such


problems, for example:

• Security in Django (especially see Cross site request forgery �CSRF� protection ).

• helmetjs referrer-policy — middleware for setting Referrer-Policy in Node.js/


Express apps (see also helmetjs for more security provisions).

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� .

• Mozilla security team guidelines on Referrer-Policy

Was this page helpful to you?

Learn how to contribute.

This page was last modified on Mar 16, 2024 by MDN contributors.

You might also like