no referrer when downgrade safari

Español – América Latina
Português – Brasil
Tiếng Việt
Collections
Safe and secure

Referer and Referrer-Policy best practices

This page outlines some best practices for setting your Referrer-Policy and using the referrer in incoming requests.

Unexpected cross-origin information leakage damages web users' privacy. A protective referrer policy can help.
Consider setting a referrer policy of strict-origin-when-cross-origin . It preserves most of the referrer's usefulness, while mitigating the risk of leaking data cross-origins.
Don't use referrers for Cross-Site Request Forgery (CSRF) protection. Use CSRF tokens instead, and other headers as an extra layer of security.

Referer and Referrer-Policy 101

HTTP requests can include an optional Referer header , which indicates the origin or web page URL the request was made from. The Referrer-Policy header defines what data is made available in the Referer header.

In the following example, the Referer header includes the complete URL of the page on site-one that the request was made from.

HTTP request including a Referer header.

The Referer header might be present in different types of requests:

Navigation requests, when a user clicks a link.
Subresource requests, when a browser requests images, iframes, scripts, and other resources that a page needs.

For navigations and iframes, you can also access this data with JavaScript using document.referrer .

You can learn a lot from Referer values. For example, an analytics service might use them to determine that 50% of the visitors on site-two.example came from social-network.example . But when the full URL, including the path and query string, is sent in the Referer across origins , it can endanger user privacy and create security risks:

URLs with paths, mapped to different privacy and security risks.

URLs #1 to #5 contain private information, and sometimes sensitive or identifying information. Leaking these silently across origins can compromise web users' privacy.

URL #6 is a capability URL . If anyone other than the intended user receives this, a malicious actor can take control of this user's account.

To restrict what referrer data is made available for requests from your site, you can set a referrer policy.

What policies are available and how do they differ?

You can select one of eight policies. Depending on the policy, the data available from the Referer header (and document.referrer ) can be:

No data (no Referer header is present)
Only the origin
The full URL: origin, path, and query string

Some policies are designed to behave differently depending on the context : cross-origin or same-origin request, whether the request destination is as secure as the origin, or both. This is useful to limit the amount of information shared across origins or to less secure origins, while maintaining the richness of the referrer within your own site.

The following table shows how referrer policies restrict the URL data available from the Referer header and document.referrer :

MDN provides a full list of policies and behavior examples .

Here are some things to be aware of when setting a referrer policy:

All policies that take the scheme (HTTPS versus HTTP) into account ( strict-origin , no-referrer-when-downgrade , and strict-origin-when-cross-origin ) treat requests from one HTTP origin to another HTTP origin the same way as requests from an HTTPS origin to another HTTPS origin, even though HTTP is less secure. That's because for these policies, what matters is whether a security downgrade takes place; that is, if the request can expose data from an encrypted origin to an unencrypted one, as in HTTPS → HTTP requests. An HTTP → HTTP request is completely unencrypted, so there's no downgrade.
If a request is same-origin , this means that the scheme (HTTPS or HTTP) is the same, so there's no security downgrade.

Default referrer policies in browsers

As of October 2021

If no referrer policy is set, the browser uses its default policy.

Best practices for setting referrer policy

There are different ways to set referrer policies for your site:

As an HTTP header
Within your HTML
From JavaScript on a per-request basis

You can set different policies for different pages, requests, or elements.

The HTTP header and the meta element are both page-level. The priority order for determining an element's effective policy is as follows:

Element-level policy
Page-level policy
Browser default

index.html :

The image is requested with a no-referrer-when-downgrade policy, and all other subresource requests from this page follow the strict-origin-when-cross-origin policy.

How to see the referrer policy?

securityheaders.com is handy to determine which policy a specific site or page is using.

You can also use the developer tools in Chrome, Edge, or Firefox to see the referrer policy used for a specific request. At the time of this writing, Safari doesn't show the Referrer-Policy header, but does show the Referer that was sent.

A screenshot of the Network panel of Chrome DevTools, showing Referer and Referrer-Policy.

Which policy should you set for your website?

We strongly recommend explicitly setting a privacy-enhancing policy such as strict-origin-when-cross-origin (or stricter).

Why "explicitly"?

If you don't set a referrer policy, the browser's default policy will be used—in fact, websites often defer to the browser's default. But this is not ideal, because:

Different browsers have different default policies, so if you rely on browser defaults, your site won't behave predictably across browsers.
Browsers are adopting stricter defaults such as strict-origin-when-cross-origin and mechanisms such as referrer trimming for cross-origin requests. Explicitly opting into a privacy-enhancing policy before browser defaults change gives you control and helps you run tests as you see fit.

Why strict-origin-when-cross-origin (or stricter)?

You need a policy that is secure, privacy-enhancing, and useful. What "useful" means depends on what you want from the referrer:

Secure : if your website uses HTTPS ( if not, make it a priority ), you don't want your website's URLs to leak in non-HTTPS requests. Since anyone on the network can see these, leaks would expose your users to person-in-the-middle-attacks. The policies no-referrer-when-downgrade , strict-origin-when-cross-origin , no-referrer , and strict-origin solve this problem.
Privacy-enhancing : for a cross-origin request, no-referrer-when-downgrade shares the full URL, which can cause privacy issues. strict-origin-when-cross-origin and strict-origin only share the origin, and no-referrer shares nothing at all. This leaves you with strict-origin-when-cross-origin , strict-origin , and no-referrer as privacy-enhancing options.
Useful : no-referrer and strict-origin never share the full URL, even for same-origin requests. If you need the full URL, strict-origin-when-cross-origin is a better option.

All of this means that strict-origin-when-cross-origin is generally a sensible choice.

Example: Setting a strict-origin-when-cross-origin policy

Or server-side, for example in Express:

What if strict-origin-when-cross-origin (or stricter) doesn't accommodate all your use cases?

In this case, take a progressive approach : set a protective policy like strict-origin-when-cross-origin for your website and, if you need to, a more permissive policy for specific requests or HTML elements.

Example: element-level policy

Safari/WebKit might cap document.referrer or the Referer header for cross-site requests. See details .

Example: request-level policy

script.js :

What else should you consider?

Your policy should depend on your website and use cases, as determined by you, your team, and your company. If some URLs contain identifying or sensitive data, set a protective policy.

Best practices for incoming requests

Here are some guidelines for what to do if your site uses the referrer URL of incoming requests.

Protect users' data

The Referer can contain private, personal, or identifying data, so make sure you treat it as such.

Incoming referrers can change {referer-can-change}

Using the referrer from incoming cross-origin requests has a few limitations:

If you have no control over the request emitter's implementation, you can't make assumptions about the Referer header (and document.referrer ) you receive. The request emitter might decide to switch to a no-referrer policy at any time , or more generally to a stricter policy than what they used before. This means you receive less data from the Referer than before.
Browsers increasingly use the Referrer-Policy strict-origin-when-cross-origin by default. This means that you might now receive only the origin, instead of a full referrer URL, in incoming cross-origin requests, if the sender site has no policy set.
Browsers might change the way they manage Referer . For example, some browser developers might decide to always trim referrers to origins in cross-origin subresource requests, to protect user privacy.
The Referer header (and document.referrer ) might contain more data than you need. For example, it might have a full URL when you only want to know if the request is cross-origin.

Alternatives to Referer

You might need to consider alternatives if:

An essential feature of your site uses the referrer URL of incoming cross-origin requests.
Your site is no longer receiving the part of the referrer URL it needs in a cross-origin request. This happens when the request emitter changes their policy or when they have no policy set and the browser default's policy changed (like in Chrome 85 ).

To define alternatives, first analyze what part of the referrer you're using.

If you only need the origin

If you're using the referrer in a script that has top-level access to the page, window.location.origin is an alternative.
If available, headers like Origin and Sec-Fetch-Site give you the Origin or describe whether the request is cross-origin, which might be exactly what you need.

If you need other elements of the URL (path, query parameters…)

Request parameters might address your use case, which saves you the work of parsing the referrer.
If you're using the referrer in a script that has top-level access to the page, window.location.pathname might work as an alternative. Extract only the path section of the URL and pass it on as an argument, so any potentially sensitive information in the URL parameters isn't passed on.

If you can't use these alternatives:

Pro: more explicit, more privacy-preserving for site-one.example users, more future-proof.
Con: potentially more work from your side or for your system's users.
Con: potentially less privacy-preserving for site-one.example users, potentially not supported in all browsers.

Cross-Site Request Forgery (CSRF) protection

A request emitter can always decide not to send the referrer by setting a no-referrer policy, and a malicious actor could even spoof the referrer.

Use CSRF tokens as your primary protection. For extra protection, use SameSite , and instead of Referer , use headers such as Origin (available on POST and CORS requests) and Sec-Fetch-Site if it's available.

Log and debug

Make sure to protect users' personal or sensitive data that might be in the Referer .

If you're only using the origin, check whether you can use the Origin header as an alternative. This might give you the information that you need for debugging purposes in a simpler way and without needing to parse the referrer.

Payment providers might rely on the Referer header of incoming requests for security checks.

For example:

The user clicks a Buy button on online-shop.example/cart/checkout .
online-shop.example redirects to payment-provider.example to manage the transaction.
payment-provider.example checks the Referer of this request against a list of allowed Referer values set up by the merchants. If it doesn't match any entry in the list, payment-provider.example rejects the request. If it does match, the user can proceed to the transaction.

Best practices for payment flow security checks

As a payment provider, you can use the Referer as a basic check against some attacks. However, the Referer header by itself isn't a reliable basis for a check. The requesting site, whether they're a legitimate merchant or not, can set a no-referrer policy that makes the Referer information unavailable to the payment provider.

Looking at the Referer might help payment providers catch naive attackers who didn't set a no-referrer policy. If you use the Referer as a first check:

When setting the list of allowed Referer values, make sure to include only the origin and no path.
For example, the allowed Referer values for online-shop.example should be online-shop.example , not online-shop.example/cart/checkout . By expecting either no Referer at all or a Referer value that is only the requesting site's origin, you prevent errors that might come from making assumptions about the merchant's Referrer-Policy .
If the Referer is absent, or if it's present and your basic Referer origin check is successful, you can move onto another, more reliable verification method.

To more reliably verify payments, let the requester hash the request parameters together with a unique key. Payment providers can then calculate the same hash on your side and only accept the request if it matches your calculation.

What happens to the Referer when an HTTP merchant site with no referrer policy redirects to an HTTPS payment provider?

No Referer is visible in the request to the HTTPS payment provider, because most browsers use strict-origin-when-cross-origin or no-referrer-when-downgrade by default when a website has no policy set. Chrome's change to a new default policy won't change this behaviour.

A protective referrer policy is a great way to give your users more privacy.

To learn more about different techniques to protect your users, see our Safe and secure collection

Understanding "same-site" and "same-origin"
A new security header: Referrer Policy (2017)
Referrer-Policy on MDN
Referer header: privacy and security concerns on MDN
Chrome change: Blink intent to implement
Chrome change: Blink intent to ship
Chrome change: status entry
Chrome change: 85 beta blogpost
Referrer trimming GitHub thread: what different browsers do
Referrer-Policy Spec

With many thanks for contributions and feedback to all reviewers - especially Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck, and Kayce Basques.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2020-07-30 UTC.

Coming soon: Apple Event on 9/9 at 10 a.m. PT

> Learn more

> Add to your calendar

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Referrer-Policy ignored

I am having issues with forcing Referrer-Polcy on Safari.

I have script tag embedded in customer site which retrieves JavaScript from our server. The script is generated at runtime based on where client is located in. This information was passed over to our server over Referrer property. Few days ago we started to experience issues with Safari clients where this property does not contain full path only host.

Narrowed it down to Referrer-Policy.

I attempted to do following:

I have added "Referrer-Policy" in HTTP Header.

I have added Meta tag in <head> with required referrer policy, also I added referrer policy attribute to the elements in question.

Seems that Referrer-Policy is ignored by Safari?!

Does anyone here know how to force it use the policy I require or have you experienced something similar?

PS. The same issue I also observed in Chrome version 85 but it was solved just by adding "referrerpolicy" attribute to script element.

Safari version: 13.1 (15609.1.20.111.8)

Policy I require: no-referrer-when-downgrade

Policies I have tried: no-referrer-when-downgrade, always

Posted on Jun 18, 2020 6:46 AM

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

Notifications You must be signed in to change notification settings

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http.headers.Referrer-Policy - Update for "Safari on iOS", Safari and IE #14675

debiru commented Jan 26, 2022 • edited Loading

I'm not sure, but I made the following difference for reference.

Did you test this? If so, how?

I built a test site for Referrer Policy and tested it on each browser. Especially, I tested about support of Default policy is strict-origin-when-cross-origin .

MDN page report details

Query: http.headers.Referrer-Policy
MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
Report started: 2022-01-26T07:55:16.261Z

The text was updated successfully, but these errors were encountered:

debiru commented Jan 26, 2022

Sorry, something went wrong.

Successfully merging a pull request may close this issue.

Referrer-Policy

The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML .

Note: The original header name Referer is a misspelling of the word "referrer". The Referrer-Policy header does not share this misspelling.

The Referer header will be omitted: sent requests do not include any referrer information.

Send the origin , path, and querystring in Referer when the protocol security level stays the same or improves (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Don't send the Referer header for requests to less secure destinations (HTTPS→HTTP, HTTPS→file).

Send only the origin in the Referer header. For example, a document at https://example.com/page.html will send the referrer https://example.com/ .

When performing a same-origin request to the same protocol level (HTTP→HTTP, HTTPS→HTTPS), send the origin , path, and query string. Send only the origin for cross origin requests and requests to less secure destinations (HTTPS→HTTP).

Send the origin , path, and query string for same-origin requests. Don't send the Referer header for cross-origin requests.

Send only the origin when the protocol security level stays the same (HTTPS→HTTPS). Don't send the Referer header to less secure destinations (HTTPS→HTTP).

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

Send the origin, path, and query string when performing any request, regardless of security.

Warning: This policy will leak potentially-private information from HTTPS resource URLs to insecure origins. Carefully consider the impact of this setting.

Integration with HTML

You can also set referrer policies inside HTML. For example, you can set the referrer policy for the entire document with a <meta> element with a name of referrer :

You can specify the referrerpolicy attribute on <a> , <area> , <img> , <iframe> , <script> , or <link> elements to set referrer policies for individual requests:

Alternatively, you can set a noreferrer link relation on an a , area , or link elements:

Warning: As seen above, the noreferrer link relation is written without a dash. When you specify the referrer policy for the entire document with a <meta> element, it should be written with a dash: <meta name="referrer" content="no-referrer"> .

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 ( strict-origin-when-cross-origin ), unless it's overwritten by a Referrer-Policy HTTP header on the CSS stylesheet's response.
For <style> elements or style attributes , the owner document's referrer policy is used.

no-referrer

No-referrer-when-downgrade, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, specify a fallback policy.

If you want to specify a fallback policy in case the desired policy hasn't got wide enough browser support, use a comma-separated list with the desired policy specified last:

In the above scenario, no-referrer is used only if the browser does not support the strict-origin-when-cross-origin policy.

Note: Specifying multiple values is only supported in the Referrer-Policy HTTP header, and not in the referrerpolicy attribute.

Browser-specific preferences/settings

Firefox preferences.

You can configure the default referrer policy in Firefox preferences. The preference names are version specific:

Firefox version 59 and later: network.http.referer.defaultPolicy (and network.http.referer.defaultPolicy.pbmode for private networks)
Firefox versions 53 to 58: network.http.referer.userControlPolicy

All of these settings take the same set of values: 0 = no-referrer , 1 = same-origin , 2 = strict-origin-when-cross-origin , 3 = no-referrer-when-downgrade .

Specifications

Browser compatibility.

Web security > Referer header: privacy and security concerns
HTTP referer on Wikipedia
When using Fetch : Request.referrerPolicy
The obsolete Content-Security-Policy 's referrer Deprecated directive.
Same-origin policy
Tighter Control Over Your Referrers – Mozilla Security Blog

Skip to main content
Skip to search
Skip to select language
Sign up for free

HTMLIFrameElement: referrerPolicy property

Baseline widely available.

This feature is well established and works across many devices and browser versions. It’s been available across browsers since September 2021 .

See full compatibility
Report feedback

The HTMLIFrameElement.referrerPolicy property reflects the HTML referrerpolicy attribute of the <iframe> element defining which referrer is sent when fetching the resource.

The Referer header will be omitted entirely. No referrer information is sent along with requests.

The URL is sent as a referrer when the protocol security level stays the same (HTTP→HTTP, HTTPS→HTTPS), but isn't sent to a less secure destination (HTTPS→HTTP).

Only send the origin of the document as the referrer in all cases. The document https://example.com/page.html will send the referrer https://example.com/ .

Send a full URL when performing a same-origin request, but only send the origin of the document for other cases.

A referrer will be sent for same-site origins , but cross-origin requests will contain no referrer information.

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

This is the user agent's default behavior if no policy is specified. Send a full URL when performing a same-origin request, only send the origin when the protocol security level stays the same (HTTPS→HTTPS), and send no header to a less secure destination (HTTPS→HTTP).

Send a full URL when performing a same-origin or cross-origin request.

Note: This policy will leak origins and paths from TLS-protected resources to insecure origins. Carefully consider the impact of this setting.

Specifications

Browser compatibility.

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

HTMLAnchorElement.referrerPolicy , HTMLAreaElement.referrerPolicy , and HTMLAreaElement.referrerPolicy .

How Chrome's new referrer policy affects your site analytics

How Chrome's new strict-origin-when-cross-origin referrer policy affects your site analytics

Google’s Chrome browser is the most popular web browser. It has a market share of more than 70%. Whatever new policy Chrome implements will have an affect on all websites as chances are the majority of your visitors use Chrome too.

In Chrome 85 which was released in August 2020, Google changed its default referrer policy to strict-origin-when-cross-origin . Firefox made the same change in March 2021 with version 87. Safari also follows the same policy.

What’s a referrer policy and what does strict-origin-when-cross-origin even mean? Why should I care as a website owner? You should be aware of it as it will affect your website analytics. Let’s take a closer look.

TL;DR: How Chrome’s new referrer policy affects your analytics

What is a referrer policy, what does chrome’s new referrer policy default do, what are the default referrer policies in other browsers, the issue of dark traffic, how can i set the referrer policy for my own website, increased importance of tagging the links you can control.

Web analytics tools will have reduced granularity in the referral sources data. Your website analytics will still be able to show the referral source of your traffic but only on the domain level rather than the full URL.

For instance, if thatblog.com/one-post/ links to you and sends you visitors, you will see thatblog.com in your referral sources list but won’t be able to see the exact post URL itself.

Most of the time the origin domain is sufficient for you to understand who has mentioned you, but in some cases, it may become more difficult to understand the exact page your traffic is coming from.

For instance, you would not be able to see the exact Reddit thread you were mentioned in anymore and would need to use Reddit search to try and find it manually.

The individual site can still pick a referrer policy of their choice. If the referring site changes its referral policy, then that policy will be followed in the browser.

Chances are some websites such as publishers and blogs will change their default referral policy to keep displaying their referring traffic in full.

As a web user navigates from one site to another, servers are informed of the URL that the user is coming from. The same happens with different resources such as images and scripts within websites. A server knows the origin of the request when a request is made.

This is done using the Referer header (it is missing an R due to the original misspelling). The Referer header helps the server where the resource is hosted understand which website is requesting that same resource.

This mechanism can be very useful for many things including for website owners to understand which other websites talk about them, link to their content and where their website traffic is originating from.

From Google’s announcement : “strict-origin-when-cross-origin offers more privacy. With this policy, only the origin is sent in the Referer header of cross-origin requests. This prevents leaks of private data that may be accessible from other parts of the full URL such as the path and query string.”

This change means that the referrer header for cross-origin requests will be reduced and you will see the top-level domain (TLD) only in the referral sources of your web analytics.

This is an example of how referrals look like when shown with a full URL path in your Plausible Analytics dashboard:

With this new policy, if I link to your site on myownblog.com/best-resources/ and someone clicks on that link, you will be able to see visitors coming from myownblog.com in your web analytics but you won’t see the exact page URL ( myownblog.com/best-resources ).

So cross-origin navigation from one website to another will no longer reveal the full path or query string information. It will only reveal the top-level domain. It will look something similar to how Facebook’s current referrer sources look like. Facebook referrer only includes the fact that the visitor comes from Facebook. It doesn’t send the post or comment ID where someone clicked.

The idea with this new policy is to reduce the potential of unexpected leaks of personal information as URLs on some commercial websites may contain sensitive user data.

In summary:

With the old no-referrer-when-downgrade the referrer shown is: https://myownblog.com/best-resources/

With the new strict-origin-when-cross-origin default, the referrer shown is: https://myownblog.com/

Chrome is using strict-origin-when-cross-origin from version 85. Strict-origin-when-cross-origin is where the full path is sent if on the same domain but only sends the domain itself if going to another domain. Previously it used no-referrer-when-downgrade .

Firefox is using strict-origin-when-cross-origin from version 87. Same as Chrome.

Edge is using strict-origin-when-cross-origin from version 85. Same as Chrome.

Safari is using strict-origin-when-cross-origin . Same as Chrome.

Brave is using no-referrer where the referrer header is completely removed. It never shares the full URL even for same-origin requests and you cannot even see the domain name for cross-origin requests.

You can read more about referrer policies here .

As you can see, not every request from a browser will have the referrer specified.

You may be familiar with the “ (direct)/(none) ” referrer source in Google Analytics, the term “ dark traffic ” or the fact that your total visitors rarely match with the total visitors of all the referral sources combined.

Dark traffic covers all the traffic where the referrer is not passed. There are many mechanisms where the referrer is not passed:

When a user navigates via a mechanism other than a link on a page such as clicks from emails, clicks from documents, clicks from mobile messengers, bookmarks or by typing in the URL directly into the browser.

Whenever someone is moving from HTTP to HTTPS or vice versa, the referrer header is dropped.

Facebook referrer only includes the fact that the visitor came from Facebook. Facebook never sends the post or comment ID where someone clicked.

Twitter sets the referrer to their link shortener so you can see the shortened link but not the actual tweet that brought the traffic.

Google does not include the search keywords in the referrer so you can see that the visitor is coming from Google search but you cannot see which keyword phrase they used to find you. In Plausible Analytics, you can integrate your Search Console data to see these search queries .

Chrome’s latest change won’t make a difference in the amount of dark traffic that you see but it will create additional “dark traffic” within the specific referrer as you won’t be able to see the exact page the other site is linking to you from.

Strict-origin-when-cross-origin may be the new default on Google’s Chrome browser, but you can still pick a policy of your choice for your site. If no referrer policy is set by the individual website, the browser’s default policy is used.

Most non-commercial websites have no risk of leaking personal or otherwise sensitive data in their URLs. This includes blogs, personal websites, publishers and so many more.

You can set the new referrer policy with a <meta> referrer tag which should be placed in the <head> section of your website. Like this:

By default, Plausible Analytics attempts to uncover traffic originating from Android apps which is traditionally categorized as direct traffic in Google Analytics and other analytics tools.

The volume of “android-app” entries in your Plausible “Top Sources” report will vary based on your site and audience. For sites with significant mobile traffic, this recovers 10% or more previously unattributed traffic from apps like Gmail, Slack and Telegram.

This reduced granularity in the referral sources data and the rise of dark traffic increases the importance of tagging the links that you can control.

To minimize the amount of traffic that falls within the “no referrer” category, you can add special query parameters such as UTM tags to your links.

When a query parameter such as the ?utm_source=<value> is present in a link, Plausible Analytics and most of the other analytics tools will show it as the referral source. Same works with the ref and source query parameters.

Read our guide on how to use UTM parameters to track your marketing campaigns .

Building Plausible: July 2020 recap

How we grew our startup from $400 to $2,750 mrr in 135 days without ads.

Made and hosted in the EU 🇪🇺 Solely funded by our subscribers.

Why Plausible?

Simple metrics
Lightweight script
Privacy focused
Open source
For creators
For agencies
For ecommerce
White label

Comparisons

vs Google Analytics
vs Cloudflare
Documentation
Data policy

Security related HTTP Headers, Part 2: Referrer Policy

Referrer Policy is a new HTTP header drafted in 2015, implemented last year. This header controls referrer header value browser sends when the user is navigating away from your website pages.

This article continues from the previous, part 1 of the Security related HTTP Headers. First part was introduction and it also described several important (and simpler) headers. You can check it out here: Security related HTTP Headers, Part 1: Introduction .

Referrer Header

Before we go on, it is important to understand what the ‘Referrer’ is. Anytime you go from one website page to another through the click on the link, the browser sends origin URL as a part of the HTTP headers block, under the name ‘referer’. This header is essential when it comes to traffic tracking and analytics because it helps us track the user while browsing the website, getting entry and exit information or calculating bounce rates.

Referrer Policy Header

Now, if you want to control when the referrer header is set in the first place when the user navigates away from your website page, you can use new Referrer Policy header. This header allows various values or combinations of values. Referrer Policy is used even when the user navigates from one to another page of your own website, referrer policy is applied to each page visited.

Basic Terminology

Here are few important terms you need to understand:

origin : URL from where the user navigates away
destination : URL where the user navigates to
protocol : communication protocol of the URL, it can be HTTP or HTTPS
downgraded protocol : HTTPS URL is the origin, and HTTP URL is the destination

Possible Values

Here is the list of allowed values for the Referrer Policy:

no-referrer : HTTP header ‘referer’ will not be set.
no-referrer-when-downgrade : If the user goes from HTTPS URL to HTTP URL, ‘referer’ will not be set.
same-origin : ‘referer’ will be set only for requests with the same origin (same website and same protocol – HTTPS or HTTP).
origin : ‘referer’ will be set, but the path of the URL will be removed, and, the domain name part of the URL will be sent.
strict-origin : this is the same as ‘origin’, but only if the protocol is not downgraded.
origin-when-cross-origin : full ‘referer’ will be set for same request origin. If that is not the case, only domain name part of the URL is sent.
strict-origin-when-cross-origin : this is the same as above, but only if the protocol is not downgraded.
unsafe-url : full ‘referer’ will be sent, regardless of the origin and destination URL.

Allowed combinations

You can set Referer Policy header to one or more of these values, comma separated. But, some combinations are not valid, and basically, used values can be in conflict. So, if you choose to use ‘no-referrer’ or ‘unsafe-url’, these two should be used alone, because they are either ‘referer’ is off, or is on for everything.

Examples for the header

Here are few examples of how to set this header for Nginx and Apache servers.

Browsers Support

All modern browsers support this header, but there are some exceptions:

MS Internet Explorer doesn’t support this header at all.
Opera Mini doesn’t support this header at all.
Safari and iOS Safari support old draft with allowed values: never , always , origin & default .
MS Edge support old draft with allowed values: never , always , origin & default .
Chrome before version 60, doesn’t support values: same-origin , strict-origin & strict-origin-when-cross-origin .
Recommendations

On Dev4Press, currently, I am using the Referrer Policy, and it is set to no-referrer-when-downgrade . It is not recommended to use no-referrer or unsafe-url values, and if you use SSL (HTTPS protocol), make sure to set to no-referrer-when-downgrade or one of the strict values. There is no way to give universal recommendations, it all depends on what you need and want to achieve, and you can easily test different values and see how it will behave.

PHP 7.3 to 8.4, free Let's Encrypt SSL certificates, cache and optimizations for WordPress. Choose between great shared WordPress hosting plans (starting from 3.95 €/month), high performance cloud hosting (starting from 64.00 €/month)...

About the author

Milan Petrovic

CEO and Lead developer of Dev4Press Web Development company, working with WordPress since 2008, first as a freelancer, later founding own development company. Author of more than 250 plugins and more than 20 themes.

Latest From The Blog

GD bbPress Toolbox Pro 7.6

September 5, 2024

SweepPress Pro / Lite 5.4

September 3, 2024

Dev4Press and Freemius: SweepPress Integration

bbPress Plugins Club

bbPress Club Membership license gives access to all Dev4Press premium plugins for bbPress. While the license remains active, it will include all future Dev4Press premium plugins for bbPress too.

Dev4Press Plugins Club

The Dev4Press Plugins Club Membership license gives access to all Dev4Press premium plugins and addons for bbPress and WordPress and all future plugins while the license is active.

Rating Plugin Club

Rating Club Membership license gives you access to the GD Rating System Pro plugin, all the free and premium addons for this plugin, and all future addons while the license is active.

Information

About Dev4Press
Development Services
Testimonials
Support Center
Subscribe to Newsletter
Newsletters Archive

From The Blog

Announcements
Development
Privacy Policy
Terms & Conditions
Press Releases

On Social Networks

Development websites, dev4press projects.

Sign up for our newsletter and receive exclusive 15% discount code!

Discount code can be used for any plugin or membership license, it can be used once and it doesn't expire. It can't be combined with other promo codes!

When you subscribe, you give us permission to send you emails about our products, exclusive promotions, and special events. However, you have the option to withdraw your consent at any point by clicking on the unsubscribe link provided in the emails.

Course bundles
Youtube channel
E-books and Guides
GTM Recipes
View All Resources
GTM Community
GA4 community

March 7, 2023

A Guide to Referrer in Google Tag Manager

Updated: March 7th, 2023 . When you create a new Google Tag Manager, you’ll see several built-in variables enabled by default. One of them is Referrer. What is it, and why is it useful? Let’s find out.

Here’s what you will learn in this article

Video tutorial

What is Referrer in GTM?
Where can I find the Referrer?

Be aware of the limitations

How to identify issues if the referrer is not returning what you expect.

#1. Multiple forms that redirect to the same “Thank you” page

#2. Prevent random visits to your “thank you” page

Frequently asked questions.

Final words

If you prefer video content, here’s a tutorial from my Youtube channel.

What is Referrer in Google Tag Manager?

In a nutshell, Referrer is a GTM variable that returns a URL of the previous page that a visitor visited. So, for example, if I am browsing the site and go from example.com/page1 to example.com/page2 , the value of the Referrer will be example.com/page1 (because that is the value of the previous page’s URL). Does this variable work only when I navigate pages between my own website? Not only that.

Is it possible to see the previous page if the visitor just landed on my site from another website? Yes, but to some extent. Due to privacy concerns, more and more limitations are affecting the Referrer. This is not just within Google Tag Manager but in general. The referrer is not just some GTM-specific thing. It is globally available on any website; anyone can access that value. That’s just how the web works.

However, there are more and more limitations introduced to referrers. Keep reading.

P.S. Your Google Analytics Acquisition reports heavily rely on the referrer variable too!

Where can I find the Referrer in Google Tag Manager?

There are multiple ways to skin the cat here. The most standard way is to use the built-in variable. In your GTM container, go to Variables , and you will find the variable in the Built-in Variables section.

You can also create a user-defined variable. Go to Variables > User-defined Variables > New > HTTP Referrer . In this case, you can extract a particular component of the referrer, e.g., the hostname.

Another option is to create a JavaScript variable (NOT Custom JavaScript ) and enter the following value (without quotation marks) — document.referrer .

But this will work like the built-in variable (therefore, there is no need to create a user-defined variable).

This variable sounds incredible, right? You could fire tags based on the page your visitor came from. For example, if a visitor lands from a particular 3rd party page, you can fire a tag that shows a specific popup.

However, Referrer is being increasingly limited (due to privacy concerns) because Referrer is more and more heavily used for cross-site tracking. And gatekeepers like Brave or Safari (but not limited to) are making this much more difficult.

The limitations are constantly changing, and if you want to stay up-to-date, bookmark cookiestatus.com .

Here is a snapshot of how Referrer is being handled by popular browsers ( click the image to see it in higher resolution ).

Let me explain some parts of the screenshot above:

Default browser policy means the referrer will be removed if a visitor navigates from https ://www.some3rdpartywebsite.com to http ://www.yourwebsite.com . It will not return any value. Why? Because the visitor navigated from HTTPS (secure) website to HTTP (insecure).
Strip all cross-origin referrer to origin means that if a visitor goes from https://www.otherwebsite.com/posts/example to https://www.yourwebsite.com , the referrer will show only https://www.otherwebsite.com ( /posts/example will be removed). So basically, you will be able to know just the domain but not the exact page from which the visitor landed on your site. Chrome 85 (and newer versions) apply this policy by default.
eTLD+1 means the Top-level Domain (TLD) (e.g. .com, .co.uk, etc.) and one additional level (e.g. amazon.co.uk or cnn.com).

First of all, let’s quickly take a look at referrer policies . They define what kind of data the website will pass to a Referrer.

no-referrer (this means that no referrer will be passed (in other words, it will be empty in GTM)).
no-referrer-when-downgrade (if a visitor navigates from an HTTPS page to HTTP, the referrer will be dropped. It will be empty in GTM)
origin (this means that the referrer will always return only the hostname (e.g., www.example.com ) of the previous page)
origin-when-cross-origin (if a visitor navigates between different subdomains, e.g., a.domain.com and b.domain.com , only the hostname will be returned. If a visitor navigates from a.domain.com/page1 to a.domain.com/page2 , the referrer will return the hostname, path , and query strings .
same-origin (referrer will be available only if a visitor navigates between pages of the same subdomain)
strict-origin (referrer will return value only if the visitor navigates from HTTPS to HTTPS
if a visitor navigates from www.example.com/pagepath to www.anotherdomain.com , the referrer will be just www.example.com (without /pagepath )
if a visitor navigates from blog.example.com/pagepath to www.example.com , the referrer will be just blog.example.com (without /pagepath ). These changes started to apply for Chrome too (since version 85).
unsafe-url (Referrer will always return a hostname, page path, and query strings. This is unsafe because the URL might contain sensitive data like email address, etc.)

You can learn more about the policies here .

Anyway, if you see an empty referrer way too often in your GTM preview mode, here are some ideas of what things to check (or if it returns the value that you did not expect):

First of all, analyze the table I’ve previously shared. There are many browsers, and they each treat the Referrer differently. Rule of thumb, don’t rely on Referrer in GTM if you try to use very specific URLs of the previous page that does not belong to the same hostname. Otherwise, you’ll face various behaviours and inconsistencies in your data.

Meta tag on the page . For example, if the previous page had a meta tag <meta name=”referrer” content=”origin”> , the referrer will only return the domain of the previous page. There are other possible values/settings of this meta tag. You can learn more about them here . Where can you find this meta tag? In the source of your site. Right-click somewhere on the previous page > View source , and then somewhere at the top of the code, you should be looking for the referrer meta tag.

If no policy is defined, the default will be used (no-referrer-when-downgrade) unless the browser is configured differently.

You can learn more about all of this here .

A couple of use cases for Referrer in Google Tag Manager

For inspiration, here are several ideas where you can possibly use the Referrer in your GTM setup.

#1. Multiple landing pages with forms that redirect to the same “Thank you” page

Let’s imagine that you have 20 landing pages with opt-in forms, for example:

https://www.example.com/lp/landing-page1
https://www.example.com/lp/landing-page2
https://www.example.com/lp/landing-page20

When a visitor submits the form, he/she is redirected to the same Confirmation page (a.k.a. “Thank you” page). The URL is always the same for all submissions, regardless of the form: https://www.example.com/thank-you.

How can you track form submissions and identify which form was submitted? You can send the value of the Referrer with every GA event, like here:

In this example, the referrer event parameter will contain the URL of the previous page (the landing page where the form was submitted). Problem solved! Also, don’t forget to register “referrer” as a custom dimension .

I will talk more about this use case here .

The problem with “Thank you” pages is that on some websites, they might be accessed a little too quickly. For example, a Google bot may have indexed that “Thank you” page. Maybe due to a mistake, even your website’s search displays that “Thank you” page in search results (obviously, your developers should fix that).

Let’s go back to my previous example with 20 landing pages. Let’s imagine that the only PROPER way to land on the “Thank you” page should be after the form is submitted on one of those 20 landing pages.

Every URL of the Landing page contains /lp/ in the page path. Why don’t you update your Pageview trigger in GTM (that activates on the “Thank you” page) and configure it to fire only if the previous page contained /lp/ ?

In that case, random visits from other parts of the site or other traffic sources will not cause false positives.

Here are several questions I’ve noticed recently being asked online, so I thought to address them as well.

Can I access the previous page’s title? There is no easy way to achieve that. The referrer is related only to the URL of the previous page, not other attributes (like Title). To access the previous page’s URL, you must write some custom JS code that temporarily stores the previous page’s title. Another option is to ask a developer to push this information to the Data Layer .

Can I access the URL of the page visited before the previous page? In other words, is it possible to access the URL of 2+ pages ago? There is no easy way for that. You must also write custom code storing the info in the cookie or browser storage. Or, once again, contact developers to push this info to the Data Layer.

Referrer in Google Tag Manager: Final words

A referrer is a handy variable in GTM; however, you should be aware of the privacy and security-related limitations that can be implemented on a site or introduced by browsers (such as Safari or Brave).

My rule of thumb:

try to use Referrer in your GTM tags or triggers only when things are happening on the same primary domain of your website (just like in the examples I’ve shared above).
If you want to know the previous page (on a 3rd party website), always expect only the hostname (domain) at best. Don’t build triggers based on a specific page of the 3rd party website (with page paths and query parameters).

Also, keep an eye on cookiestatus.com . More limitations will be introduced, so you should stay current.

Have any questions? The comments section is at your service.

16 COMMENTS

Mar 17 2020

We use to track all the people who directly arrive on a 404 page so that we can the identify the source and suggest a better page

Also very handy to identify which pages contain bad links

Mar 28 2020

I liked the second idea: #2. Prevent random visits to your “thank you” page. Will be adding a referrer condition to prevent direct landings there.

May 21 2020

Hi! Helpful article :) What about this use case: To validate a form submission, a user clicks on a confirmation link from an email received earlier. This leads the user to a "Thank-You" page. How to avoid tracking accidental pageView here? In this case, the referrer will be empty (more accurately, what is shown in The Google Tage Manager Preview Debug window is ''). What rule should be specified in the trigger to avoid firing the tag in that scenario? There is no such rule as Referrer Is Empty, which would have done the job here. Thank you for considering that case :)

Ask a developer to add UTM parameters to the confirmation link and use that in your trigger.

Hi there, I have a question. When I use {{referrer}} to register the previously visited page, it takes along the URL parameters if there are any. For instance, the previous page had "?utm_campaign=Advertisement&utm_source=LinkedIn" in its URL and that is how it's captured in the referrer variable. How would I ensure the referrer records the URL without parameters?

You'd need a custom JS variable for that and write code. Or install the URL variable 2.0 from the custom variable template gallery

Nov 19 2020

Hi Julius, great post like always. I have a form that redirects to the same page (via the variable action of the form), then, if the subscriber is saved successfully, this second page (which is the same as the first one, the page with the form) is redirected to a third page (the thank you page) via javascript. Should I edit the 'action' attribute of the form to send the user directly from the first form page to the thank you page? Or does it work if the second page (which is the same as the first one) is redirected to the thank you page via javascript when the subscriber is saved successfully? Is the referrer method useful in this case? Thank you very much.

Nov 23 2020

Hey Julius,

I am trying to get a referrer variable of the previous URL of each event on my tag manager (My web app is a Single Page Application). Unfortunately, the referrer only points to the https://tagassistant.google.com/' when I use the preview mode of tag manager. I cant see any change when I navigate and the URL path is switching.

Any Idea why it doesn't works ? there is any tutorial can help me define such variable ?

Feb 23 2021

Thanks for this guide altogether, but can i use this to check mailchimp as well?

Does this work for a referral from Google itself? You used to see query terms from google in the referrer (and still can with Bing/Internet Explorer combination) but newer browsers hide the query for privacy reasons. Queries in GA are disconnected from the later user flow. Ideally, would want to look for conversion (e.g. form submit) related to original search engine terms.

You cannot read google search's query parameters. Impossible. Google's referrer policy prevents that

I just found out about this Julius yesterday. I must have spent 2 whole days before I found this article and the article I used yesterday. Thank you for such a knowledgeable post.

I'm using referrer for my thank you pages and with a set cookie that fires based on this condition to avoid duplicate conversions.

I have two of the same opt-in forms on two different landing pages for split testing. One is on the homepage (https://mydomain.com) and the other sits on this page (https://mydomain.com/free-gifts/

My current trigger condition uses the referrer matches Regex with the home page URL (mydomain.com)

How can I add the second URL as an "or" RegEx condition on one line. Would it be mydomain.com|mydomain.com/free-gifts/ or mydomain.com|/free-gifts/?

I took a look at the examples presented in this blog: https://www.analyticsmania.com/post/or-condition-in-google-tag-manager-triggers-3-options/ and was still a little confused.

Any help most greatly appreciated!

Keep up the phenomenal work. I love the way you're so intricate and thorough with your explanations. This is what people need, especially ones not acute to code/programming. Thanks again pal and God bless!

hello Julius how we get previous page A url if user reload page/back example : visit page A , then reload page A visit page A, click page B, then back to page A i wanna how many people back form B to A, think used cookie have you had any solution Many thanks for replay

Isn't "page_referrer" default parameter enough for GA4?

Referrer-Policy

The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests. Aside from the HTTP header, you can set this policy in HTML .

Note: The original header name Referer is a misspelling of the word "referrer". The Referrer-Policy header does not share this misspelling.

The Referer header will be omitted: sent requests do not include any referrer information.

Send only the origin in the Referer header. For example, a document at https://example.com/page.html will send the referrer https://example.com/ .

When performing a same-origin request to the same protocol level (HTTP→HTTP, HTTPS→HTTPS), send the origin , path, and query string . Send only the origin for cross origin requests and requests to less secure destinations (HTTPS→HTTP).

Send the origin , path, and query string for same-origin requests. Don't send the Referer header for cross-origin requests.

Send only the origin when the protocol security level stays the same (HTTPS→HTTPS). Don't send the 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 .

Send the origin, path, and query string when performing any request, regardless of security.

Warning: This policy will leak potentially-private information from HTTPS resource URLs to insecure origins. Carefully consider the impact of this setting.

Integration with HTML

You can also set referrer policies inside HTML. For example, you can set the referrer policy for the entire document with a <meta> element with a name of referrer :

You can specify the referrerpolicy attribute on <a> , <area> , <img> , <iframe> , <script> , or <link> elements to set referrer policies for individual requests:

Alternatively, you can set a noreferrer link relation on an a , area , or link elements:

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 ( strict-origin-when-cross-origin ), unless it's overwritten by a Referrer-Policy HTTP header on the CSS stylesheet's response.
For <style> elements or style attributes , the owner document's referrer policy is used.

no-referrer

No-referrer-when-downgrade, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, specify a fallback policy.

If you want to specify a fallback policy in case the desired policy hasn't got wide enough browser support, use a comma-separated list with the desired policy specified last:

In the above scenario, no-referrer is used only if the browser does not support the strict-origin-when-cross-origin policy.

Note: Specifying multiple values is only supported in the Referrer-Policy HTTP header, and not in the referrerpolicy attribute.

Browser-specific preferences/settings

Firefox preferences.

You can configure the default referrer policy in Firefox preferences. The preference names are version specific:

Firefox version 59 and later: network.http.referer.defaultPolicy (and network.http.referer.defaultPolicy.pbmode for private networks)
Firefox versions 53 to 58: network.http.referer.userControlPolicy

All of these settings take the same set of values: 0 = no-referrer , 1 = same-origin , 2 = strict-origin-when-cross-origin , 3 = no-referrer-when-downgrade .

Specifications

Browser compatibility.

Web security > Referer header: privacy and security concerns
HTTP referer on Wikipedia
When using Fetch : Request.referrerPolicy
The obsolete Content-Security-Policy 's referrer directive.
Same-origin policy
Tighter Control Over Your Referrers – Mozilla Security Blog

HTML References

Html <iframe> referrerpolicy attribute.

❮ HTML <iframe> tag

Specifies that no referrer information will be sent along with the request:

Definition and Usage

The referrerpolicy attribute specifies which referrer information to send when fetching an iframe.

Browser Support

The numbers in the table specify the first browser version that fully supports the attribute.

Attribute Values

COLOR PICKER

Contact Sales

If you want to use W3Schools services as an educational institution, team or enterprise, send us an e-mail: [email protected]

Report Error

If you want to report an error, or if you want to make a suggestion, send us an e-mail: [email protected]

SPFx issues with the new Referrer-Policy in Chrome >= 85

Since version 85 of Chrome, the default referrer policy has changed from no-referrer-when-downgrade to strict-origin-when-cross-origin . This change might have a significant impact on your SharePoint Framework solutions when they rely on the referrer header (or better, the referer header with a single “r”).

What is the referrer header?

Whenever your browser does an API call, the referrer header gets used to indicate the page’s origin from where it was performed.

With the previous default in Chrome ( no-referrer-when-downgrade ), this would be the full URL of the page in SharePoint. Example: https://tenant.sharepoint.com/sites/<site>/SitePages/just-a-page.aspx .

With the new policy, the URL provided changes from the full URL to the origin URL. Example: https://tenant.sharepoint.com/ .

What is the impact?

On the Google Chrome documentation page, they mention that visual impact is expected to be limited.

When building solutions only in SharePoint, this will not generate any impact when used without a back-end. If you use a back-end and use the referrer header as a validation mechanism, this will impact your solution. As you now receive the SharePoint tenant URL, instead of the absolute page URL.

Info Read more about the new default referrer policy in Chrome on: A new default Referrer-Policy for Chrome: strict-origin-when-cross-origin

What with other browsers?

Only Chrome and Safari seem to be using the strict-origin-when-cross-origin referrer-policy at the moment by default.

Microsoft Edge and Firefox are still using the no-referrer-when-downgrade policy, but be aware, for Microsoft Edge, they are experimenting with the strict-origin-when-cross-origin policy, and the Firefox team is considering to move as well.

You can follow the status of the browser implementations here: https://github.com/privacycg/proposals/issues/13

What can you do for now?

If you rely on the referrer header for your API, best is to specify the referrerPolicy for these calls as follows:

The result should be that the full URL now gets provided when calling the API.

Report issues or make changes on GitHub

Found a typo or issue in this article? Visit the GitHub repository to make changes or submit a bug report.

Parse multipart/form-data in Azure Function
Retrieving the CosmosDB query continuation token in Node.js
Parse application/x-www-form-urlencoded in Azure Function

Español – América Latina
Português – Brasil
Tiếng Việt
Chrome for Developers

A new default Referrer-Policy for Chrome - strict-origin-when-cross-origin

Before we start:

If you're unsure of the difference between "site" and "origin", check out Understanding "same-site" and "same-origin" .
The Referer header is missing an R, due to an original misspelling in the spec. The Referrer-Policy header and referrer in JavaScript and the DOM are spelled correctly.
Browsers are evolving towards privacy-enhancing default referrer policies, to provide a good fallback when a website has no policy set.
Chrome plans to gradually enable strict-origin-when-cross-origin as the default policy in 85; this may impact use cases relying on the referrer value from another origin.
This is the new default, but websites can still pick a policy of their choice.
To try out the change in Chrome, enable the flag at chrome://flags/#reduced-referrer-granularity . You can also check out this demo to see the change in action.
Beyond the referrer policy, the way browsers deal with referrers might change—so keep an eye on it.

What's changing and why?

HTTP requests may include the optional Referer header , which indicates the origin or web page URL the request was made from. The Referer-Policy header defines what data is made available in the Referer header, and for navigation and iframes in the destination's document.referrer .

Exactly what information is sent in the Referer header in a request from your site is determined by the Referrer-Policy header you set.

When no policy is set, the browser's default is used. Websites often defer to the browser’s default.

For navigations and iframes, the data present in the Referer header can also be accessed via JavaScript using document.referrer .

Up until recently, no-referrer-when-downgrade has been a widespread default policy across browsers. But now many browsers are in some stage of moving to more privacy-enhancing defaults .

Chrome plans to switch its default policy from no-referrer-when-downgrade to strict-origin-when-cross-origin , starting in version 85 .

This means that if no policy is set for your website, Chrome will use strict-origin-when-cross-origin by default. Note that you can still set a policy of your choice; this change will only have an effect on websites that have no policy set.

What does this change mean?

strict-origin-when-cross-origin offers more privacy . With this policy, only the origin is sent in the Referer header of cross-origin requests.

This prevents leaks of private data that may be accessible from other parts of the full URL such as the path and query string.

For example:

Cross-origin request, sent from https://site-one.example/ stuff/detail?tag=red to https://site-two.example/…:

With no-referrer-when-downgrade : Referer: https://site-one.example/ stuff/detail?tag=red .
With strict-origin-when-cross-origin : Referer: https://site-one.example/.

What stays the same?

Like no-referrer-when-downgrade , strict-origin-when-cross-origin is secure : no referrer ( Referer header and document.referrer ) is present when the request is made from an HTTPS origin (secure) to an HTTP one (insecure). This way, if your website uses HTTPS ( if not, make it a priority ), your website's URLs won't leak in non-HTTPS requests—because anyone on the network can see these, so this would expose your users to man-in-the-middle-attacks.
Within the same origin, the Referer header value is the full URL.

For example: Same-origin request, sent from https://site-one.example/ stuff/detail?tag=red to https://site-one.example/…:

With strict-origin-when-cross-origin : Referer: https://site-one.example/ stuff/detail?tag=red

What's the impact?

Based on discussions with other browsers and Chrome's own experimentation run in Chrome 84, user-visible breakage is expected to be limited .

Server-side logging or analytics that rely on the full referrer URL being available are likely to be impacted by reduced granularity in that information.

What do you need to do?

Chrome plans to start rolling out the new default referrer policy in 85 (July 2020 for beta, August 2020 for stable). See status in the Chrome status entry .

Understand and detect the change

To understand what the new default changes in practice, you can check out this demo .

You can also use this demo to detect what policy is applied in the Chrome instance you are running.

Test the change, and figure out if this will impact your site

You can already try out the change starting from Chrome 81: visit chrome://flags/#reduced-referrer-granularity in Chrome and enable the flag. When this flag is enabled, all websites without a policy will use the new strict-origin-when-cross-origin default.

You can now check how your website and backend behave.

Another thing to do to detect impact is to check if your website's codebase uses the referrer—either via the Referer header of incoming requests on the server, or from document.referrer in JavaScript.

Certain features on your site might break or behave differently if you're using the referrer of requests from another origin to your site (more specifically the path and/or query string) AND this origin uses the browser's default referrer policy (i.e. it has no policy set).

If this impacts your site, consider alternatives

If you're using the referrer to access the full path or query string for requests to your site, you have a few options:

Use alternative techniques and headers such as Origin and Sec-fetch-Site for your CSRF protection, logging, and other use cases. Check out Referer and Referrer-Policy: best practices .
You can align with partners on a specific policy if this is needed and transparent to your users. Access control—when the referrer is used by websites to grant specific access to their resources to other origins—might be such a case although with Chrome's change, the origin will still be shared in the Referer Header (and in document.referrer ).

Note that most browsers are moving in a similar direction when it comes to the referrer (see browser defaults and their evolutions in Referer and Referrer-Policy: best practices .

Implement an explicit, privacy-enhancing policy across your site

What Referer should be sent in requests originated by your website, i.e. what policy should you set for your site?

Even with Chrome's change in mind, it's a good idea to set an explicit, privacy-enhancing policy like strict-origin-when-cross-origin or stricter right now.

This protects your users and makes your website behave more predictably across browsers. Mostly, it gives you control —rather than having your site depend on browser defaults.

Check Referrer and Referrer-Policy: best practices for details on setting a policy.

About Chrome enterprise

The Chrome enterprise policy ForceLegacyDefaultReferrerPolicy is available to IT administrators who would like to force the previous default referrer policy of no-referrer-when-downgrade in enterprise environments. This allows enterprises additional time to test and update their applications.

This policy will be removed in Chrome 88.

Send feedback

Do you have feedback to share or something to report? Share feedback on Chrome's intent to ship , or tweet your questions at @maudnals .

With many thanks for contributions and feedback to all reviewers - especially Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck and Kayce Basques.

Referer and Referrer-Policy: best practices
Understanding "same-site" and "same-origin"
Chrome status entry
Chrome 85 beta blog post
Blink intent to implement
Blink intent to ship

Last updated 2020-07-30 UTC.

Referrer Policy

Editor’s Draft , 28 August 2024

This document describes how an author can set a referrer policy for documents they create, and the impact of such a policy on the Referer HTTP header for outgoing requests and navigations.

Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

Changes to this document may be tracked at https://github.com/w3c/webappsec .

The ( archived ) public mailing list [email protected] (see instructions ) is preferred for discussion of this specification. When sending e-mail, please put the text “REFERRER-POLICY” in the subject, preferably like this: “[REFERRER-POLICY] …summary of comment… ”

This document was produced by the Web Application Security Working Group .

This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .

This document is governed by the 03 November 2023 W3C Process Document .

1. Introduction

This section is not normative.

Requests made from a document, and for navigations away from that document are associated with a Referer header. While the header can be suppressed for links with the noreferrer link type, authors might wish to control the Referer header more directly for a number of reasons:

1.1. Privacy

A social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands. The social networking site might not wish to leak the user’s profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).

Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user’s profile contained the links.

1.2. Security

A web application uses HTTPS and a URL-based session identifier. The web application might wish to link to HTTPS resources on other web sites without leaking the user’s session identifier in the URL.

Alternatively, a web application may use URLs which themselves grant some capability. Controlling the referrer can help prevent these capability URLs from leaking via referrer headers. [CAPABILITY-URLS]

Note that there are other ways for capability URLs to leak, and controlling the referrer is not enough to control all those potential leaks.

1.3. Trackback

A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive trackback links.

2. Key Concepts and Terminology

Every environment settings object has an algorithm for obtaining a referrer policy , which is used by default for all requests with that environment settings object as their client .

3. Referrer Policies

A referrer policy is the empty string, " no-referrer ", " no-referrer-when-downgrade ", " same-origin ", " origin ", " strict-origin ", " origin-when-cross-origin ", " strict-origin-when-cross-origin ", or " unsafe-url ".

Each possible referrer policy is explained below. A detailed algorithm for evaluating their effect is given in the § 5 Integration with Fetch and § 8 Algorithms sections.

Note: The referrer policy for an environment settings object provides a default baseline policy for requests when that environment settings object is used as a request client . This policy may be tightened for specific requests via mechanisms like the noreferrer link type.

The default referrer policy is " strict-origin-when-cross-origin " .

3.1. " no-referrer "

The simplest policy is " no-referrer " , which specifies that no referrer information is to be sent along with requests to any origin . The header Referer will be omitted entirely.

3.2. " no-referrer-when-downgrade "

The " no-referrer-when-downgrade " policy sends a request’s full referrerURL stripped for use as a referrer for requests:

Requests whose referrerURL is a potentially trustworthy URL and whose current URL is a non- potentially trustworthy URL on the other hand, will contain no referrer information. A Referer HTTP header will not be sent.

Navigations from that same page to http ://not.example.com/ would send no Referer header.

3.3. " same-origin "

The " same-origin " policy specifies that a request’s full referrerURL is sent as referrer information when making same-origin-referrer requests .

Cross-origin-referrer requests , on the other hand, will contain no referrer information. A Referer HTTP header will not be sent.

Navigations from that same page to https:// not .example.com/ would send no Referer header.

This is because the descendant script request’s current URL is https://example.com/descendant.js , while its referrerURL is https://script.example.com , making the request cross-origin-referrer .

3.4. " origin "

The " origin " policy specifies that only the ASCII serialization of the request’s referrerURL is sent as referrer information when making both same-origin-referrer requests and cross-origin-referrer requests .

Note: The serialization of an origin looks like https://example.com . To ensure that a valid URL is sent in the ` Referer ` header, user agents will append a U+002F SOLIDUS (" / ") character to the origin (e.g. https://example.com/ ).

Note: The " origin " policy allows the origin of HTTPS referrers to be sent over the network as part of unencrypted HTTP requests. The " strict-origin " policy addresses this concern.

3.5. " strict-origin "

The " strict-origin " policy sends the ASCII serialization of the origin of the referrerURL for requests:

Navigations from that same page to http:// not.example.com would send no Referer header.

3.6. " origin-when-cross-origin "

The " origin-when-cross-origin " policy specifies that a request’s full referrerURL is sent as referrer information when making same-origin-referrer requests , and only the ASCII serialization of the origin of the request’s referrerURL is sent as referrer information when making cross-origin-referrer requests .

Note: For the " origin-when-cross-origin " policy, we also consider protocol upgrades, e.g. requests from http://example.com/ to https://example.com/ , to be cross-origin-referrer requests .

Note: The " origin-when-cross-origin " policy allows the origin of HTTPS referrers to be sent over the network as part of unencrypted HTTP requests. The " strict-origin-when-cross-origin " policy addresses this concern.

Navigations from that same page to https://not.example.com/ would send a Referer header with a value of https://example.com/ , even to URLs that are not potentially trustworthy URL s.

3.7. " strict-origin-when-cross-origin "

The " strict-origin-when-cross-origin " policy specifies that a request’s full referrerURL is sent as referrer information when making same-origin-referrer requests , and only the ASCII serialization of the origin of the request’s referrerURL when making cross-origin-referrer requests :

Navigations from that same page to https://not.example.com/ would send a Referer header with a value of https://example.com/ .

This policy is the user agent’s default , and will be applied if no policy is otherwise specified.

3.8. " unsafe-url "

The " unsafe-url " policy specifies that a request’s full referrerURL is sent along for both same-origin-referrer requests and cross-origin-referrer requests .

Note: The policy’s name doesn’t lie; it is unsafe. This policy will leak origins and paths from secure resources to insecure origins. Carefully consider the impact of setting such a policy for potentially sensitive documents.

3.9. The empty string

The empty string "" corresponds to no referrer policy , causing a fallback to a referrer policy defined elsewhere, or in the case where no such higher-level policy is available, falling back to the default referrer policy . This happens in Fetch’s main fetch algorithm, for example.

4. Referrer Policy Delivery

A request ’s referrer policy is delivered in one of five ways:

4.1. Delivery via Referrer-Policy header

The Referrer-Policy HTTP header specifies the referrer policy that the user agent applies when determining what referrer information should be included with requests made, and with browsing contexts created from the context of the protected resource.

The syntax for the name and value of the header are described by the following ABNF grammar. ABNF is defined in [RFC5234] , and the #rule ABNF extension used below is defined in Section 5.6.1 of [RFC9110] .

Note: The header name does not share the HTTP Referer header’s misspelling.

Note: The purpose of extension-token is so that browsers do not fail to parse the entire header field if it includes an unknown policy value. § 11.1 Unknown Policy Values describes in greater detail how new policy values can be deployed.

Note: The quotes in the ABNF above are used to indicate literal strings. Referrer-Policy header values should not be quoted.

§ 5 Integration with Fetch and § 6 Integration with HTML describe how the Referrer-Policy header is processed.

4.1.1. Usage

A protected resource can prevent referrer leakage by specifying no-referrer as the value of its Referrer-Policy header:

This will cause all requests made from the protected resource’s context to have an empty Referer [sic] header.

4.2. Delivery via meta

The HTML Standard defines the referrer keyword for the meta element, which allows setting the referrer policy via markup.

4.3. Delivery via a referrerpolicy content attribute

The HTML Standard defines the concept of referrer policy attributes which applies to several of its elements, for example:

4.4. Referrer Policy Inheritance

Referrer policy is inherited following the inheritance mechanism of policy containers , as defined by HTML.

5. Integration with Fetch

The Fetch specification calls out to § 8.2 Set request’s referrer policy on redirect before Step 13 of the HTTP-redirect fetch , so that a request’s referrer policy can be updated before following a redirect.

The Fetch specification calls out to § 8.3 Determine request’s Referrer as Step 8 of the Main fetch algorithm , and uses the result to set the request ’s referrer property. Fetch is responsible for serializing the URL provided, and setting the ` Referer ` header on request .

6. Integration with HTML

The HTML Standard determines the referrer policy of any response received during navigation or while running a worker , and uses the result to set the resulting Document 's policy container ’s or WorkerGlobalScope 's policy container ’s referrer policy .

7. Integration with CSS

The CSS Standard does not specify how it fetches resources referenced from stylesheets. However, implementations should be sure to set the referrer-related properties of any requests initiated by stylesheets as follows:

This requires that CSS style sheets process `Referrer-Policy` headers, and store a referrer policy in the same way that Documents do .

Note: Both the value of the request ’s referrer and referrer policy are set based on the values at the time a given request is created. If a document’s referrer policy changes during its lifetime, the policy associated with inline stylesheet requests will also change.

8. Algorithms

8.1. parse a referrer policy from a referrer-policy header.

Given a response response , the following steps return a referrer policy according to response ’s ` Referrer-Policy ` header:

Note: This algorithm loops over multiple policy values to allow deployment of new policy values with fallbacks for older user agents, as described in § 11.1 Unknown Policy Values .

8.2. Set request ’s referrer policy on redirect

Given a request request and a response actualResponse , this algorithm updates request ’s referrer policy according to the Referrer-Policy header (if any) in actualResponse .

8.3. Determine request ’s Referrer

Given a request request , we can determine the correct referrer information to send by examining its referrer policy as detailed in the following steps, which return either no referrer or a URL:

Note: If request ’s referrer is " no-referrer ", Fetch will not call into this algorithm.

Note: This same-origin check determines whether or not the request is same-origin-referrer .

8.4. Strip url for use as a referrer

Certain portions of URLs must not be included when sending a URL as the value of a ` Referer ` header: a URLs fragment, username, and password components must be stripped from the URL before it’s sent out. This algorithm accepts a origin-only flag , which defaults to false . If set to true , the algorithm will additionally remove the URL’s path and query components, leaving only the scheme, host, and port.

9. Privacy Considerations

9.1. user controls.

Nothing in this specification should be interpreted as preventing user agents from offering options to users which would change the information sent out via a ` Referer ` header. For instance, user agents MAY allow users to suppress the referrer header entirely, regardless of the active referrer policy on a page.

10. Security Considerations

10.1. information leakage.

The referrer policies " origin " , " origin-when-cross-origin " and " unsafe-url " might leak the origin and the URL of a secure site respectively via insecure transport.

Those three policies are included in the spec nevertheless to lower the friction of sites adopting secure transport.

Authors wanting to ensure that they do not leak any more information than the default policy should instead use the policy states " same-origin " , " strict-origin " , or " no-referrer " .

10.2. Downgrade to less strict policies

The spec does not forbid downgrading to less strict policies, e.g., from " no-referrer " to " unsafe-url " .

On the one hand, it is not clear which policy is more strict for all possible pairs of policies: While " no-referrer-when-downgrade " will not leak any information over insecure transport, and " origin " will, the latter reveals less information across cross-origin navigations.

On the other hand, allowing for setting less strict policies enables authors to define safe fallbacks as described in § 11.1 Unknown Policy Values .

11. Authoring Considerations

11.1. unknown policy values.

As described in § 8.1 Parse a referrer policy from a Referrer-Policy header and in the meta referrer algorithm, unknown policy values will be ignored, and when multiple sources specify a referrer policy, the value of the latest one will be used. This makes it possible to deploy new policy values.

or, equivalently, multiple comma-separated header values:

This behavior does not, however, apply to the referrerpolicy attribute. Authors may dynamically set and get the referrerpolicy attribute to detect whether a particular policy value is supported.

12. Acknowledgements

This specification is based in large part on Adam Barth and Jochen Eisinger’s Meta referrer document.

Francois Marier contributed the same-origin , strict-origin , and strict-origin-when-cross-origin policies.

Conformance

Document conventions.

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example" , like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note" , like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Terms defined by this specification

Terms defined by reference, normative references, informative references, issues index.

element can be used to provide document metadata in terms of name-value pairs, with the name attribute giving the metadata name, and the content attribute giving the value.">Element/meta/name

In all current engines.

Headers/Referrer-Policy

IMAGES

No refresh in Safari
No refresh in Safari
Safari Shifts To Google Secure Search in iOS 6, Causing Search Referrer
Reset Safari To Default Settings On Mac And IOS [2023 Guide]
Safari 5 to Safari 4 Downgrade
How To Reset Your Safari Web Browser

VIDEO

NEW alcazar 2024 detailed review☝ll Upgrade or downgrade😱??.. HARRIER.. SAFARI khatre mai..?
Hyenas Distracted By Eating a Hippo Get Ambushed By Lion
কেনিয়া সাফারিতে আপনি কী দেখতে পারেন African Safari Tour
enepi(エネピ)プロパンガスの申し込み
Safari бесконечно перезагружает страницу
Restarting SpringBoard by crashing Safari

COMMENTS

Safari mobile and desktop are hiding full referrer URL: why?
The value that is sent as the Referer header is determined by the Referrer Policy in effect for a given request. The chosen policy can come from a browser default, a HTTP header, a meta tag, or an attribute on the individual tag.. The difference you're seeing is probably because browsers are moving from a default of no-referrer-when-downgrade (which would show the full path in your case) to ...
Referrer-Policy
Referrer-Policy - HTTP - MDN Web Docs
Referrer policy configuration
While there are other Referrer-Policy directives, they do not protect user privacy or limit exposure as effectively as the options listed above. In recent versions of Firefox and Safari, "unsafe" directives (no-referrer-when-downgrade, origin-when-cross-origin, and unsafe-url) behave like strict-origin-when-cross-origin.
Referer and Referrer-Policy best practices
Browser Default Referrer-Policy / Behavior; Chrome: The default is strict-origin-when-cross-origin.: Firefox: The default is strict-origin-when-cross-origin. Starting from version 93, for Strict Tracking Protection and Private Browsing users, the less restrictive referrer policies no-referrer-when-downgrade, origin-when-cross-origin, and unsafe-url are ignored for cross-site requests, meaning ...
Referrer-Policy ignored
I am having issues with forcing Referrer-Polcy on Safari. I have script tag embedded in customer site which retrieves JavaScript from our server. The script is generated at runtime based on where client is located in. ... Policies I have tried: no-referrer-when-downgrade, always. Show more Less. Posted on Jun 18, 2020 6:46 AM
In what cases HTTP referer will be truncated
Edge is using no-referrer-when-downgrade. Same as Firefox. Safari is using strict-origin-when-cross-origin. Same as Chrome. Brave is using no-referrer where the referrer header is completely removed. It never shares the full URL even for same-origin requests and you cannot even see the domain name for cross-origin requests.
Change default referrer policy to "no-referrer-when-downgrade"
After the discussions in #7060 and the implementation in #7088 we've discovered that Safari doesn't play well with our default of origin-when-cross-origin therefore preventing services such as fonts.com and others which rely on the referrer information from working.. I suggest we change our default to no-referrer-when-downgrade which is the same as the default browser policy.
http.headers.Referrer-Policy
It is written as No (No support) for iOS Safari and IE in the MDN. But current iOS Safari supports it as well as Safari. https://developer.... Skip to content. Navigation Menu Toggle navigation. Sign in ... Safari 14.1.2: no-referrer-when-downgrade: Native macOS: Safari 15.0: unknown (no test) nothing: Safari 15.3: strict-origin-when-cross ...
Referrer-Policy
no-referrer-when-downgrade. Send the origin, path, and querystring in Referer when the protocol security level stays the same or improves (HTTP→HTTP, HTTP→HTTPS, ... Safari WebView Android Chrome Android Firefox for Android Opera Android Safari on IOS Samsung Internet; Referrer-Policy: 56. 79. 50. No. 43. 11.1. 56. 56. 50. 43. 12. 7.2.
HTML <a> referrerpolicy Attribute
Value Description; no-referrer: No referrer information is sent: no-referrer-when-downgrade: Default. Sends the origin, path, and query string if the protocol security level stays the same or is higher (HTTP to HTTP, HTTPS to HTTPS, HTTP to HTTPS is ok).
HTMLIFrameElement: referrerPolicy property
No referrer information is sent along with requests. no-referrer-when-downgrade. The URL is sent as a referrer when the protocol security level stays the same (HTTP→HTTP, HTTPS→HTTPS), but isn't sent to a less secure destination (HTTPS→HTTP). origin. Only send the origin of the document as the referrer in all cases. ...
How Chrome's new referrer policy affects your site analytics
Previously it used no-referrer-when-downgrade. Firefox is using strict-origin-when-cross-origin from version 87. Same as Chrome. Edge is using strict-origin-when-cross-origin from version 85. Same as Chrome. Safari is using strict-origin-when-cross-origin. Same as Chrome. Brave is using no-referrer where the referrer header is completely ...
Security related HTTP Headers, Part 2: Referrer Policy
Here is the list of allowed values for the Referrer Policy: no-referrer: HTTP header 'referer' will not be set. no-referrer-when-downgrade: If the user goes from HTTPS URL to HTTP URL, 'referer' will not be set. same-origin: 'referer' will be set only for requests with the same origin (same website and same protocol - HTTPS or HTTP).
A Guide to Referrer in Google Tag Manager
If no policy is defined, the default will be used (no-referrer-when-downgrade) unless the browser is configured differently. You can learn more about all of this here. A couple of use cases for Referrer in Google Tag Manager. For inspiration, here are several ideas where you can possibly use the Referrer in your GTM setup. #1.
Referrer-Policy
Directives no-referrer. The Referer header will be omitted: sent requests do not include any referrer information.. no-referrer-when-downgrade. Send the origin, path, and querystring in Referer when the protocol security level stays the same or improves (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). Don't send the Referer header for requests to less secure destinations (HTTPS→HTTP, HTTPS→file).
Stop link from sending referrer to destination
The HTTP Referrer Policy spec lets you control referrer-sending for links and subresources (images, scripts, stylesheets, etc.) and, at the moment, it's supported on Firefox, Chrome, Opera, and Desktop Safari 11.1. Edge, IE11, iOS Safari, and desktop versions of Safari prior to 11.1 support an older version of the spec with never, always ...
HTML <iframe> referrerpolicy Attribute
no-referrer. No referrer information will be sent along with a request. no-referrer-when-downgrade. Default. The referrer header will not be sent to origins without HTTPS. origin. Send only scheme, host, and port to the request client. origin-when-cross-origin. For cross-origin requests: Send only scheme, host, and port.
SPFx issues with the new Referrer-Policy in Chrome >= 85
Since version 85 of Chrome, the default referrer policy has changed from no-referrer-when-downgrade to strict-origin-when-cross-origin. This change might have a significant impact on your SharePoint Framework solutions when they rely on the referrer header (or better, the referer header with a single "r"). ... Only Chrome and Safari seem to ...
A new default Referrer-Policy for Chrome
Up until recently, no-referrer-when-downgrade has been a widespread default policy across browsers. But now many browsers are in some stage of moving to more privacy-enhancing defaults. Chrome plans to switch its default policy from no-referrer-when-downgrade to strict-origin-when-cross-origin, starting in version 85.
Referrer Policy
4. Referrer Policy Delivery. A request's referrer policy is delivered in one of five ways:. Via the Referrer-Policy HTTP header (defined in § 4.1 Delivery via Referrer-Policy header).; Via a meta element with a name of referrer.; Via a referrerpolicy content attribute on an a, area, img, iframe, link, or script element.; Via the noreferrer link relation on an a, or area element.
Referrer Policy: no-referrer-when-downgrade fetch api
I have created API using AWS API gateway and while creating individual GET call selected "Use Lambda Proxy integration", and allow cors on that resource. But after publishing API its works fine I a...

Referer and Referrer-Policy best practices

Referer and Referrer-Policy 101

What policies are available and how do they differ?

Default referrer policies in browsers

Best practices for setting referrer policy

How to see the referrer policy?

Which policy should you set for your website?

Why "explicitly"?

Why strict-origin-when-cross-origin (or stricter)?

What if strict-origin-when-cross-origin (or stricter) doesn't accommodate all your use cases?

Example: element-level policy

Example: request-level policy

What else should you consider?

Best practices for incoming requests

Protect users' data

Incoming referrers can change {referer-can-change}

Alternatives to Referer

If you only need the origin

If you need other elements of the URL (path, query parameters…)

If you can't use these alternatives:

Cross-Site Request Forgery (CSRF) protection

Log and debug

Best practices for payment flow security checks

Similar questions

Navigation Menu

Saved searches

http.headers.Referrer-Policy - Update for "Safari on iOS", Safari and IE #14675

debiru commented Jan 26, 2022 • edited Loading

Did you test this? If so, how?

MDN page report details

debiru commented Jan 26, 2022

Referrer-Policy

Integration with HTML

Integration with CSS

no-referrer

Browser-specific preferences/settings

Specifications

HTMLIFrameElement: referrerPolicy property

Specifications

How Chrome's new referrer policy affects your site analytics

TL;DR: How Chrome’s new referrer policy affects your analytics

Building Plausible: July 2020 recap

Why Plausible?

Comparisons

Security related HTTP Headers, Part 2: Referrer Policy

Referrer Header

Referrer Policy Header

Basic Terminology

Possible Values

Allowed combinations

Examples for the header

Browsers Support

About the author

Milan Petrovic

Leave a Comment Cancel reply

Latest From The Blog

GD bbPress Toolbox Pro 7.6

SweepPress Pro / Lite 5.4

Dev4Press and Freemius: SweepPress Integration

bbPress Plugins Club

Dev4Press Plugins Club

Rating Plugin Club

Information

From The Blog

On Social Networks

Sign up for our newsletter and receive exclusive 15% discount code!

A Guide to Referrer in Google Tag Manager

Video tutorial

Be aware of the limitations

#2. Prevent random visits to your “thank you” page

What is Referrer in Google Tag Manager?

Where can I find the Referrer in Google Tag Manager?

A couple of use cases for Referrer in Google Tag Manager

#1. Multiple landing pages with forms that redirect to the same “Thank you” page

Referrer in Google Tag Manager: Final words

16 COMMENTS

Leave a comment Cancel reply

Referrer-Policy

Integration with HTML

Integration with CSS