Add additional security and privacy controls for referrer policies

[rshaner-stripe]

The current implementation of the Referrer-Policy header provides several options to control how much information is included with requests. The current 5 options allow a website to configure sending no header, only the host domain, or the full URL including query string – with some distinctions between same-origin and cross-origin requests. While this gives important safeguards for user privacy and security, some scenarios require further control, specifically a need to understand page-level referrer analytics while still safeguarding from the disclosure of possibly sensitive path parameters.

Additional referrer policy values that allow for more control over where and how the referrer is passed to target domains would be very useful in a variety of scenarios.

Use Case

As maintainers of large websites, it is often important to know which page certain cohorts of traffic originated from. Consider a web property, foo.com, that includes links to various subdomains such as bar.foo.com and baz.foo.com (or another domain entirely).

In our current setup, we face a dilemma: we have little control over which of our domains the browser sends referrer information to. Additionally, we are limited to sending the entire referring URL (which often contains sensitive query or path parameters) or only the origin (which lacks useful context for analytics).

Scenario	Referring URL	Referrer Policy	Referrer Sent
Unsafe Referral (Query Parameters) ❌	https://foo.com/login?token=asdf	no-referrer-when-downgrade	https://foo.com/login?token=asdf
Unsafe Referral (Path Parameters) ❌	https://foo.com/account/asdf	no-referrer-when-downgrade	https://foo.com/account/asdf
Safe Referral ✅	https://foo.com/pricing?plan=pro	no-referrer-when-downgrade	https://foo.com/pricing?plan=pro

Being able to configure which domains the browser could send full referrer information to would enable us to only send this information to targets we trust or own. One may consider it both safer and more privacy-friendly to send to domains under your control than to all third-party sites. The -same-origin policy helps ensure that referrer information is only sent on requests to the same origin, but does not provide this additional context in the case of requests to subdomains or other related websites.

Another option to send just the path, such as "/login," (omitting query parameters) would allow for some additional safety. Importantly, this is not to say that sensitive information couldn't also be part of the page path, but it is far less common in practice, and a website who added sensitive information to the path should be discouraged from using this option.

Potential Solutions

1. Additional referrer policies to only send referrer information to same-site

This solution proposes new options for the Referrer-Policy header that, upon navigation, only provides referrer when the destination corresponds to same-site.

Technical Specification

Create a new “same-site” option of existing relevant Referrer-Policy values - for these options, the browser should only send referrer information to destinations that are considered same-site.

• same-site: Send the origin, path, and query string for same-site requests. Don't send the Referer header for cross-origin requests.
• strict-same-site-when-cross-origin: Send the origin, path, and query string when performing a same-site 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).

Examples

same-site

From document	Navigation to	Referrer used
https://foo.com/page	https://foo.com/otherpage	https://foo.com/page
https://foo.com/page	https://login.foo.com/otherpage	https://foo.com/page
https://foo.com/page	https://bar.com/otherpage	(no referrer)

strict-same-site-when-cross-origin

From document	Navigation to	Referrer used
https://foo.com/page	https://foo.com/otherpage	https://foo.com/page
https://foo.com/page	https://login.foo.com/otherpage	https://foo.com/page
https://foo.com/page	https://example.com/otherpage	https://foo.com/
https://foo.com/page	http://example.com/otherpage	(no referrer)

2. Additional referrer policies to only send referrer information to related websites

This solution proposes new options for the Referer-Policy header that, upon navigation, only provides referrer information when the destination is in a Related Website Set. This is very similar to the previous proposal, but allows for the additional flexibility of also sending to referrer information to safe domains that are not necessarily subdomains.

Technical Specification

Create a new “related” option of existing relevant Referrer-Policy values - for these options, the browser should only send referrer information to destinations that are in a Related Website Set.

• related: Send the origin, path, and query string when performing a request to a destination corresponding to a related website. Don't send the Referer header for cross-origin requests.
• strict-related-when-cross-origin: Send the origin, path, and query string when performing a request to a destination corresponding to a related website. For cross-origin requests not corresponding to a related website, send the origin (only) when the protocol security level stays the same (HTTPS→HTTPS). Don't send the Referer header to less secure destinations (HTTPS→HTTP).

Examples

Related Website Set

{
  "sets": [
    {
      "contact": "...",
      "primary": "https://foo.com",
      "associatedSites": [
        "https://bar.com",
        "https://baz.com",
      ],
  ],
  ...
}

related

From document	Navigation to	Referrer used
https://foo.com/page	https://foo.com/otherpage	https://foo.com/page
https://foo.com/page	https://bar.com/otherpage	https://foo.com/page
https://foo.com/page	https://example.com/otherpage	(no referrer)

strict-related-when-cross-origin:

From document	Navigation to	Referrer used
https://foo.com/page	https://foo.com/otherpage	https://foo.com/page
https://foo.com/page	https://bar.com/otherpage	https://foo.com/page
https://foo.com/page	https://example.com/otherpage	https://foo.com/
https://foo.com/page	http://example.com/otherpage	(no referrer)

3. Additional referrer policies to exclude query parameters

This solution proposes new options for the Referrer-Policy header that upon navigation, when a user is directed from a page with this policy applied, the referrer would include both the origin and path of the referring URL while omitting any query parameters.

Technical Specification

Create a new "no-query-" prefix option of existing relevant Referrer-Policy values – for these options, the browser should send the origin and path of the referring URL but exclude any query or hash parameters

• no-query-no-referrer-when-downgrade: Send the origin and path (but not query string) 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).
• no-query-same-origin: Send the origin and path (but not query string) for same-origin requests. Don't send the Referer header for cross-origin requests.
• no-query-strict-origin-when-cross-origin: Send the origin and path (but not query string) when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays the same (HTTPS→HTTPS). Don't send the Referer header to less secure destinations (HTTPS→HTTP).

Examples

same-origin-path

From document	Navigation to	Referrer used
https://foo.com/page?param=1	https://foo.com/otherpage	https://foo.com/page
https://foo.com/page?param=1	https://mozilla.org	(no referrer)

no-referrer-when-downgrade-path

From document	Navigation to	Referrer used
https://foo.com/page?param=1	https://foo.com/otherpage	https://foo.com/page
https://foo.com/page?param=1	https://bar.org	https://foo.com/page
https://foo.com/page?param=1	http://foo.com	(no referrer)
https://foo.com/page?param=1	anywhere	https://foo.com/page

Addendum (Separation Between Policy and Target Destination)

The solutions above generally propose adding new values to the Referrer-Policy header. In the current state of the world, the Referrer-Policy header defines controls over both what referrer information is sent and where the information is sent to. As new options are added, the combination between what information should be in the referral and where it should be sent becomes numerous and somewhat unwieldy. It may be beneficial to define a new header that separates these two concerns. A separate header that defines where referrer information is sent may also allow for the opportunity to be much more granular in choosing targets.

For example, imagine a Referer-Policy-Target header that allows for a configurable set of options:

Referrer-Policy-Target: *

From document	Navigation to	Referrer information sent
https://foo.com/	https://foo.com/otherpage	Yes ✅
https://foo.com/	https://bar.foo.com/otherpage	Yes ✅
https://foo.com/	https://baz.com/otherpage	Yes ✅

Referrer-Policy-Target: same-origin

From document	Navigation to	Referrer information sent
https://foo.com/	https://foo.com/otherpage	Yes ✅
https://foo.com/	https://bar.foo.com/otherpage	No ❌
https://foo.com/	https://baz.com/otherpage	No ❌

Referrer-Policy-Target: same-origin, https://baz.com

From document	Navigation to	Referrer information sent
https://foo.com/	https://foo.com/otherpage	Yes ✅
https://foo.com/	https://bar.foo.com/otherpage	No ❌
https://foo.com/	https://baz.com/otherpage	Yes ✅

The examples above are not exhaustive but provide a general idea of how a Referrer-Policy-Target header may be represented/configured. This solution could potentially fold in/stay compatible with some of the proposed changes above (e.g. same-site and no-query specifiers).