The Referrer-Policy header controls how much of the current page address the browser puts in the Referer header on outgoing requests. Most modern browsers default to strict-origin-when-cross-origin. Set it explicitly, and keep tokens and personal data out of URLs, because no policy can hide what you put there.
What leaks and why it matters
When a user clicks a link or your page loads an image, script or frame from another site, the browser may tell that site where the request came from. Depending on policy, that can include the path and the query string.
Paths and query strings sometimes hold reset tokens, document ids, search terms or session hints. A third-party analytics host or image CDN then sees them in its logs. MDN warns that the unsafe-url value can leak private information from HTTPS URLs to insecure origins.
What each value sends
| Value | Sent on a cross-origin HTTPS request |
|---|---|
| no-referrer | Nothing |
| same-origin | Nothing (full URL for same-origin requests) |
| strict-origin | Origin only |
| strict-origin-when-cross-origin | Origin only (full URL same-origin) |
| origin-when-cross-origin | Origin only, even on downgrade |
| origin | Origin only, always |
| no-referrer-when-downgrade | Full URL |
| unsafe-url | Full URL, always |
The older browser default was no-referrer-when-downgrade, which sends the full URL to any HTTPS destination. The current default per MDN is strict-origin-when-cross-origin. It also applies when the value you supply is invalid.
Choosing a value
For most apps, strict-origin-when-cross-origin is a sound choice and matches the default. Setting it in the header means a future browser change cannot alter your exposure.
Pages with sensitive paths, such as admin tools or account recovery, can use no-referrer or same-origin. The cost is that other sites lose attribution data, and some partner integrations rely on the header. Test them first.
Avoid unsafe-url unless you have a documented reason.
Referrer-Policy: strict-origin-when-cross-origin
You can also list a fallback for older browsers in the header, for example no-referrer followed by strict-origin-when-cross-origin. The browser uses the last value it understands. That list form works only in the header, not in the referrerpolicy attribute.
Per-element overrides
An iframe takes a referrerpolicy attribute, and the same idea exists on links and images. Use it when one embed needs tighter handling than the page, such as a third-party widget on a page with a long query string.
Side effect to know about
For form posts and other requests that are not CORS, the Origin header becomes null under no-referrer. Under same-origin it is null for cross-origin requests. A backend that rejects requests with a null Origin, as some CSRF checks do, may then block legitimate submissions. Check your CSRF logic before tightening.
A Safeguard note
Header settings like this belong in a release checklist. Safeguard's policies and gates can hold the review step for a pull request, and the free scan at gold.safeguard.sh/scan checks the dependencies behind the third-party scripts you embed.
Quick check
Does no-referrer break analytics?
It removes the source site from the header on outgoing requests, so other sites cannot see where visitors came from. Your own analytics usually measure incoming referrers, which depend on the policy of the site that links to you.
Is the default enough?
It is a reasonable baseline. Setting the header yourself documents the intent and protects against changes in default behavior.
Sources
Last reviewed: 19 October 2026.
