Referrer-Policy, control what the Referer header leaks

Referrer-Policy controls how much of the current URL leaks in the Referer header when users navigate away. Values, defaults, and the safe choice.

Every time a user follows a link, and every time a page loads a cross-origin resource (an image, a script, an iframe, an analytics beacon), the browser tells the destination which page the request came from in the Referer header (a historical misspelling of "referrer" that stuck). That address can include the origin, the path, and the query string of the current page, so whatever lives in your URLs travels with it: password-reset and other capability links, search queries, personal data in paths. It goes to analytics providers, CDNs, ad networks, and every site you link to.

Referrer-Policy is the response header that controls how much of that URL goes out, from the full address down to nothing at all. This is the value to ship on every HTML response (see the recommendation):

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

Values and what each does

In the table, "full URL" means origin plus path plus query string; the browser never sends the fragment (#...) or embedded credentials under any policy. "Downgrade" means a request from an HTTPS page to a plain HTTP destination.

Value	Status	What is sent
`no-referrer`	✅ Good	Nothing, on any request.
`no-referrer-when-downgrade`	❌ Risky	Full URL everywhere, nothing on downgrade. The pre-2020 legacy default.
`origin`	✅ Good	Origin only, everywhere, even on downgrade.
`origin-when-cross-origin`	✅ Good	Full URL same-origin, origin cross-origin and on downgrade.
`same-origin`	✅ Good	Full URL same-origin, nothing cross-origin.
`strict-origin`	✅ Good	Origin only, nothing on downgrade.
`strict-origin-when-cross-origin`	✅ Good	Full URL same-origin, origin cross-origin, nothing on downgrade.
`unsafe-url`	❌ Risky	Full URL everywhere, including on downgrade.

The names read systematically: a strict- prefix means nothing is sent on a downgrade, and a -when-cross-origin suffix means the full URL stays on same-origin requests while less goes out cross-origin.

When a page sends no policy, every current engine defaults to strict-origin-when-cross-origin; Chrome, Firefox, and Safari all adopted this default in recent years. Before that change the default was no-referrer-when-downgrade, which sends the full URL to every cross-origin destination.

The header is not the only delivery form. A <meta name="referrer" content="..."> tag does the same job in markup, a referrerpolicy attribute on a, area, img, iframe, script, and link elements sets a policy for one element, and rel="noreferrer" on a link omits the Referer header entirely (it also implies noopener).

What it protects against

URL secrets leaking to third parties. Capability URLs (password-reset links, invite links, signed URLs), search queries, and personal data in paths otherwise arrive at every analytics script, CDN, ad tag, and linked site. A strict policy strips the path and query before the request leaves the browser.
Cross-site tracking granularity. A full referrer tells a third party exactly which page the user was on, not just which site. Sending the origin only is data minimization; both Mozilla and Chrome framed the default change as a privacy improvement.

It is not a CSRF defense. The Referer header is too unreliable to build request-forgery protection on; use CSRF tokens and check the Origin or Sec-Fetch-Site headers server-side instead, as web.dev's referrer best practices spell out.

Risks without it

Omitting the header is no longer the leak it used to be, because the current browser default is already strict-origin-when-cross-origin. Set it explicitly anyway. Defaults vary across browser versions and change over time (the current one only arrived between 2020 and 2021), an older browser still applies no-referrer-when-downgrade and sends the full URL to every cross-origin destination, and a single lax value in a stray meta tag or element attribute silently reintroduces the leak. An explicit header states the policy you chose instead of inheriting whatever the browser ships.

Risks and gotchas when using it

Analytics lose page-level detail. With origin-only values, the sites you link to (and their analytics) see https://api-next.centralcsp.com/ instead of the full page path. Domain-level source attribution keeps working.
You cannot loosen it everywhere. Safari caps all cross-site referrers at the origin regardless of your policy (Intelligent Tracking Prevention), and Firefox (with Tracking Protection) ignores the lax values (unsafe-url, no-referrer-when-downgrade, origin-when-cross-origin) on cross-site requests. unsafe-url cannot restore full cross-site referrers outside Chromium.
Element attributes win. A referrerpolicy attribute on a link, image, script, or iframe overrides the page policy for that element, in either direction.
Fallback syntax works in the header only. Referrer-Policy: no-referrer, strict-origin-when-cross-origin is valid; browsers skip unknown values and the last recognized one wins. The comma syntax does not work in the referrerpolicy attribute.
no-referrer can break Referer-based checks. Some payment and fraud-detection flows and hotlink checks require a Referer; going fully silent site-wide can break them.

How to set it up

Set Referrer-Policy: strict-origin-when-cross-origin on all HTML responses. The policy applies to the document that received it, so cover every page, not just the home page.

For individually sensitive outbound links, cut the referrer at the element level:

<a href="https://example.net/partner-portal" rel="noreferrer">Partner portal</a>

Check the deployed header, and the rest of your response headers, with the security headers scanner.

Recommendation

Send Referrer-Policy: strict-origin-when-cross-origin on every HTML response:

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

This is the value the OWASP HTTP Headers cheat sheet recommends: the full URL stays within your own site, cross-origin destinations get the origin only, and nothing is sent on a downgrade. It matches the current browser default, but set it explicitly rather than relying on defaults. If your URLs carry secrets even for same-origin navigation (reset tokens, signed URLs), step up to no-referrer and accept that Referer-based checks stop working.

Browser support

Baseline widely available: the header is supported in every current browser, so support is effectively universal, and all current engines default to strict-origin-when-cross-origin when no policy is set. Browsers can also be stricter than your policy: Safari caps cross-site referrers at the origin regardless (Intelligent Tracking Prevention), and Firefox ignores the lax values on cross-site requests with Tracking Protection.

FAQ

What is strict-origin-when-cross-origin?

It is the default policy in every current browser. On same-origin requests it sends the full URL, meaning origin, path, and query. On cross-origin requests it sends only your origin. On a downgrade from HTTPS to HTTP it sends nothing. It keeps paths and queries off other sites while preserving domain-level attribution.

Does Referrer-Policy break Google Analytics?

No. A stricter policy reduces referrer granularity, so a destination site and your inbound reports see your origin rather than the full path, but domain-level source attribution keeps working. Analytics that group traffic by referring domain are unaffected; only the path-level referrer detail is trimmed on cross-origin requests.

What is the difference between referer and referrer?

Referer is the request header the browser attaches, and its name is a historical misspelling that stuck in the HTTP standard. Referrer-Policy, the response header that controls it, and document.referrer, the JavaScript property that exposes it, are both spelled correctly. Same concept, one word misspelled for compatibility.

Referrer-Policy