@@ -30,10 +30,6 @@
Syntax
-
-
The original header name {{HTTPHeader("Referer")}} is a misspelling of the word "referrer". The Referrer-Policy
header does not share this misspelling.
-
-
Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
@@ -44,30 +40,41 @@ Syntax
Referrer-Policy: unsafe-url
+
+
Note
+
The original header name {{HTTPHeader("Referer")}} is a misspelling of the word "referrer". The Referrer-Policy
header does not share this misspelling.
+
+
Directives
no-referrer
- The {{HTTPHeader("Referer")}} header will be omitted entirely. No referrer information is sent along with requests.
- no-referrer-when-downgrade
(default)
- - This is the default behavior if no policy is specified, or if the provided value is invalid. The {{glossary("origin")}}, path, and querystring of the URL are sent as a referrer when the protocol security level stays the same (HTTP→HTTP, HTTPS→HTTPS) or improves (HTTP→HTTPS), but isn't sent to less secure destinations (HTTPS→HTTP).
-
There is effort from browsers in moving to a stricter default value, namely
strict-origin-when-cross-origin
(see
https://github.com/whatwg/fetch/pull/952), consider using this value (or a stricter one), if possible, when changing the Referrer-Policy.
+ no-referrer-when-downgrade
+ - Send the {{glossary("origin")}}, path, and querystring in {{HTTPHeader("Referer")}} when the protocol security level stays the same or improves (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS. Don't send the {{HTTPHeader("Referer")}} header for requests to less secure destinations (HTTPS→HTTP, HTTPS→file).
origin
- - Only send the {{glossary("origin")}} of the document as the referrer.
+ - Send the {{glossary("origin")}} (only) in the {{HTTPHeader("Referer")}} header.
For example, a document at https://example.com/page.html
will send the referrer https://example.com/
.
origin-when-cross-origin
- - Send the {{glossary("origin")}}, path, and query string when performing a {{glossary("Same-origin_policy", "same-origin")}} request, but only send the origin of the document for other cases.
+ - Send the {{glossary("origin")}}, path, and query string when performing a {{glossary("Same-origin_policy", "same-origin")}} request to the same protocol level. Send origin (only) for cross origin requests and requests to less secure destinations.
same-origin
- - A referrer will be sent for same-site origins, but cross-origin requests will send no referrer information.
+ - Send the {{glossary("origin")}}, path, and query string for {{glossary("Same-origin_policy", "same-origin")}} requests. Don't send the {{HTTPHeader("Referer")}} header for cross-origin requests.
strict-origin
- - Only send the origin of the document as the referrer when the protocol security level stays the same (HTTPS→HTTPS), but don't send it to a less secure destination (HTTPS→HTTP).
- strict-origin-when-cross-origin
- - Send the origin, path, and querystring when performing a same-origin request, only send the origin when the protocol security level stays the same while performing a cross-origin request (HTTPS→HTTPS), and send no header to any less-secure destinations (HTTPS→HTTP).
+ - Send the origin (only) when the protocol security level stays the same (HTTPS→HTTPS). Don't send the {{HTTPHeader("Referer")}} header to less secure destinations (HTTPS→HTTP).
+ strict-origin-when-cross-origin
(default)
+ - Send the origin, path, and querystring when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don't send the {{HTTPHeader("Referer")}} header to less secure destinations (HTTPS→HTTP).
+
+
+
Note
+
This is the default policy if no policy is specified, or if the provided value is invalid (see spec revision November 2020). Previously the default was no-referrer-when-downgrade
.
+
+
unsafe-url
- Send the origin, path, and query string when performing any request, regardless of security.
-
This policy will leak potentially-private information from HTTPS resource URLs to insecure origins. Carefully consider the impact of this setting.
+
Warning
+
This policy will leak potentially-private information from HTTPS resource URLs to insecure origins. Carefully consider the impact of this setting.
@@ -78,7 +85,7 @@ Integration with HTML
<meta name="referrer" content="origin">
-Or set it for individual requests with the referrerpolicy
attribute on {{HTMLElement("a")}}, {{HTMLElement("area")}}, {{HTMLElement("img")}}, {{HTMLElement("iframe")}}, {{HTMLElement("script")}}, or {{HTMLElement("link")}} elements:
+Or set it for individual requests with the referrerpolicy
attribute on {{HTMLElement("a")}}, {{HTMLElement("area")}}, {{HTMLElement("img")}}, {{HTMLElement("iframe")}}, {{HTMLElement("script")}}, or {{HTMLElement("link")}} elements:
<a href="http://example.com" referrerpolicy="origin">
@@ -87,7 +94,8 @@ Integration with HTML
<a href="http://example.com" rel="noreferrer">
-
As seen above, the noreferrer
link relation is written without a dash — noreferrer
. When the referrer policy is specified for the entire document with a {{HTMLElement("meta")}} element, it's written with a dash: <meta name="referrer" content="no-referrer">
.
+
Warning
+
As seen above, the noreferrer
link relation is written without a dash — noreferrer
. When the referrer policy is specified for the entire document with a {{HTMLElement("meta")}} element, it's written with a dash: <meta name="referrer" content="no-referrer">
.
Integration with CSS
@@ -95,8 +103,8 @@ Integration with CSS
CSS can fetch resources referenced from stylesheets. These resources follow a referrer policy as well:
- - External CSS stylesheets use the default policy (
no-referrer-when-downgrade
), unless it's overwritten via a Referrer-Policy
HTTP header on the CSS stylesheet’s response.
- - For {{HTMLElement("style")}} elements or
style
attributes, the owner document's referrer policy is used.
+ - External CSS stylesheets use the default policy (
strict-origin-when-cross-origin
), unless it's overwritten via a Referrer-Policy
HTTP header on the CSS stylesheet’s response.
+ - For {{HTMLElement("style")}} elements or
style
attributes, the owner document's referrer policy is used.
Examples
@@ -232,25 +240,10 @@ Browser compatibility
{{Compat("http.headers.Referrer-Policy")}}
-
-
- - From version 53 onwards, Gecko has a pref available in
about:config
to allow users to set their default Referrer-Policy
— network.http.referer.userControlPolicy
.
- - From version 59 onwards (See #587523), this has been replaced by
network.http.referer.defaultPolicy
and network.http.referer.defaultPolicy.pbmode
.
-
-
-
Possible values are:
-
-
- - 0 —
no-referrer
- - 1 —
same-origin
- - 2 —
strict-origin-when-cross-origin
- - 3 —
no-referrer-when-downgrade
(the default)
-
-
-
See also
+ - Web security > Referer header: privacy and security concerns
- {{interwiki("wikipedia", "HTTP_referer", "HTTP referer on Wikipedia")}}
- When using Fetch: {{domxref("Request.referrerPolicy")}}
- The obsolete {{HTTPHeader("Content-Security-Policy")}} {{HTTPHeader("Content-Security-Policy/referrer", "referrer")}} {{Obsolete_Inline}} directive.
diff --git a/files/en-us/web/security/referer_header_colon__privacy_and_security_concerns/index.html b/files/en-us/web/security/referer_header_colon__privacy_and_security_concerns/index.html
index ec1f1e008407c08..2ae7fa4e56807f1 100644
--- a/files/en-us/web/security/referer_header_colon__privacy_and_security_concerns/index.html
+++ b/files/en-us/web/security/referer_header_colon__privacy_and_security_concerns/index.html
@@ -12,26 +12,26 @@
The referrer problem
-The {{httpheader("Referer")}} (sic) header contains the address of the previous web page from which a link to the currently requested page was followed, which has lots of 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.
+The {{httpheader("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 hosted on a third party side but 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.
+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?
-Much of this risk can be mitigated by sensible design of applications. A sensible application would remove such risks by making password reset URLs only usable for a single use, or when combined with a unique user token, and transmitting sensitive data in different ways.
+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 {{HTTPMethod("POST")}} rather than {{HTTPMethod("GET")}} wherever possible, to avoid passing sensitive data to other locations via URLs.
-You should always use {{glossary("HTTPS")}} for your sites. This has many security advantages, including the fact that HTTPS sites will never transmit referer information to non-HTTPS sites. This is becoming less useful in this context now that most of the web is using HTTPS, but it is still a worthy consideration.
+You should always use {{glossary("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 {{htmlelement("iframe")}}) from secure areas of your website, like password reset pages, payment forms, login areas, etc.
You can also mitigate such risks using:
- - The {{httpheader("Referrer-Policy")}} header on your server to control what information is sent through the
Referer
header. Again, a directive of no-referrer
would omit the Referer header entirely.
+ - The {{httpheader("Referrer-Policy")}} header on your server to control what information is sent through the {{httpheader("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 {{HTMLElement("img")}} and {{HTMLElement("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 {{HTMLElement("img")}} and {{HTMLElement("a")}}). See Link types and search for noreferrer
for more information.
- The Exit page technique.