Referrer-Policy: which URL information is shared

A missing header does not automatically mean a data leak

The current specification default is strict-origin-when-cross-origin. Within the same origin, the sanitised full URL may be sent; for other origins, generally only the origin. In the ordinary transition from public HTTPS to unencrypted HTTP, no referrer is sent. Browsers may reduce the information further. Chrome introduced this default from version 85, Firefox from 87. Older reports about previous browser defaults therefore do not necessarily describe present behaviour. Referrer Policy § 3, Chrome's change, Firefox's change

The Web Security Check evaluates the header received in the final response and its recognised policy values. It does not observe browser requests and therefore captures neither later meta or element policies nor JavaScript telemetry. Its assessment is not a measurement of all data actually transmitted.

Compare the eight values

An origin consists of scheme, host and port. Another subdomain or port is therefore cross-origin, even when both addresses belong to the same company. ‘URL’ in the table means the address without user information or a fragment (#…), but generally including the path and query. For ordinary HTTP(S) web addresses:

The table describes policy rules, not guaranteed transmission to every recipient. The draft determines a security downgrade from the trustworthiness of the URLs; local loopback addresses are therefore not a general test for public HTTPS-to-HTTP transitions. Very long referrers may be shortened to the origin, and privacy features may impose further restrictions. Referrer Policy: determining and sanitising the referrer

For an ordinary website, setting the default explicitly is an understandable starting point:

Referrer-Policy: strict-origin-when-cross-origin

If even the source origin is confidential, or a sensitive page should send no referrers, consider no-referrer. This may change attribution and certain poorly designed integrations. Check these data flows before changing the setting; the Referer should not be the sole access control.

Tokens and analytics: the remaining transmission paths

A reset page using unsafe-url may also reveal a query parameter in the referrer of a cross-origin request. This schematic example explicitly assumes that permissive policy:

Referrer-Policy: unsafe-url

Source page: https://app.example.com/reset?token=SYNTHETISCH
Resource:    https://metrics.example.net/pixel
Possible Referer: https://app.example.com/reset?token=SYNTHETISCH

With an effective strict-origin-when-cross-origin policy, only https://app.example.com/ remains in this ordinary cross-origin case. no-referrer omits that information too. However, neither policy removes the parameter from the address bar, server logs or a link explicitly constructed with it.

An included script runs in the page's context and can read its address independently of the referrer. The PoPETs study by Zagi, Moti and Acar (2025) examines this distinction using its own sample of websites. Its percentage is neither a current rate across all websites nor evidence of a browser defect; for configuration, the important distinction remains between the header and script data. Original publication

Analytics is not generally ‘same-origin’ either. GA4 configuration uses document.location as the default for page_location and document.referrer for page_referrer. These are separately collected measurement parameters. A stricter Referrer-Policy does not automatically switch off this measurement or change UTM parameters in the destination address. Check the requests actually sent and the analytics settings chosen. Google: GA4 configuration fields

Headers, meta elements and individual requests

There is no general rule that ‘the strictest value wins’. The response header sets the initial document policy. A processed meta element can change it for subsequent requests; attributes and Fetch options can govern individual requests differently. A meta element inserted late cannot retrieve requests already sent. HTML: referrer metadata

<meta name="referrer" content="strict-origin-when-cross-origin">
<a href="https://partner.example.net/" referrerpolicy="no-referrer">Partner</a>

fetch('/konto/status', { referrerPolicy: 'no-referrer' });

The relative Fetch call is a model for your own application, not a tested account function. For a link, rel="noreferrer" can also suppress referrer transmission. A header policy is therefore not an immutable security boundary against JavaScript already executing in your document.

Multiple values in the HTTP header form a fallback list: the browser uses the last value it recognises. This example is syntactically valid, but usually unnecessary for current target browsers:

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

This list rule does not apply to referrerpolicy attributes or the meta element. Avoid unintended duplication between the application and CDN. Redirect responses can also influence the policy of the continued request; examine the chain. External stylesheets may have their own referrer and policy context for resources they subsequently load. Referrer Policy: delivery and integration

Roll out a change safely

1. Identify sensitive URLs, third-party resources, outgoing links and required attribution. Also consider whether confidential data should be in the URL at all.
2. Set the header at the responsible point in the delivery chain, and check meta elements, element attributes and scripts for consistency.
3. Open your own test pages in the target browsers. Inspect the Referer actually sent in the network panel, not just the response header. Check same-origin and cross-origin requests, redirects and particularly sensitive pages.
4. Check analytics and required partner journeys using synthetic data. An empty document.referrer does not prove that no other information was transmitted.
5. Keep the previous setting ready for rollback. Reverting affects newly loaded responses; cached documents may continue to use the old state. Data already transmitted is not retrieved by doing so.

Data protection depends on the actual data flow

URL information may be confidential or personal data. A suitable policy can reduce data transmission, but a missing header alone establishes neither a data protection breach nor, when present, compliance. Origin, destination URL, script telemetry and logging also belong in the assessment. Further reading: web security and compliance.