Referrer Policy: What strict-origin-when-cross-origin Actually Sends

You ran a header check, and the report came back with a deduction next to Referrer-Policy. Now you've got two questions stacked on top of each other: what does this header actually control, and if you fix it, will your Google Analytics numbers go haywire? Both are fair questions, and both have clean, sourced answers.

A referrer policy governs one thing only, how much of the previous page's URL your browser hands over when it follows a link or loads a resource. It has nothing to do with the CORS error that shares this exact phrase in Chrome's console (that's a different problem, about fetch responses, not about the header we're discussing here) so if you landed on this page chasing a console message, you're in the wrong place. If you landed here because a checker flagged your header, keep reading.

What Does Referrer-Policy Do?

Every time your browser navigates to a new page or requests an image, script, or stylesheet from another domain, it can attach a Referer header (yes, that's the historical misspelling baked into HTTP since the 1990s) that tells the receiving server where the request came from. Left unmanaged, that header can leak more than site owners realize: internal search terms sitting in a URL, a password reset link a user clicked from an email, a document path that reveals your CMS structure, or a session-like token someone tacked onto a query string out of habit.

The Referrer-Policy header is how a site owner takes control of that leak. It's a single directive that tells the browser exactly how much of the referring URL to send, and to whom. Set it too loosely and you're handing full paths to any third party your page talks to. Set it too tightly and you lose referral data you might actually want, the kind that tells you a visitor arrived from a partner site or a specific campaign page.

According to MDN's reference documentation, the header accepts eight possible values, ranging from sending nothing at all to sending everything, full URL included, regardless of where the request is headed.

That range is exactly why a checker flags a missing or misconfigured Referrer-Policy header. No header at all leaves the decision to the browser's built-in default, which is safer than it used to be but still worth setting explicitly. A permissive header leaks data you probably didn't mean to share. Neither outcome is catastrophic on its own, but both are worth fixing in five minutes once you understand what you're choosing between.

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

This is the value your checker most likely wants to see, and for good reason: it's the browser default as of late 2020, which means it's also the value most sites end up with even without setting anything. Explicitly declaring it just makes the behavior consistent across older browsers that haven't caught up to the newer default.

The name looks intimidating, but the logic is a simple three-tier rule based on where the request is going:

Put plainly: your own pages get the full picture, other HTTPS sites get to know you exist and which domain sent the visitor, and anything insecure gets told nothing. That last case, a request downgrading from HTTPS to HTTP, is also exactly what HSTS exists to prevent from happening at all: once a site enforces Strict-Transport-Security, the browser refuses to make the plain HTTP request in the first place, so Referrer-Policy's downgrade rule becomes a backstop rather than your only defense.

That's the balance MDN describes when it defines the value, and it's the same balance the Chrome team cited when they made it Chrome's default starting with Chrome 85 in August 2020. Google's stated goal was straightforward: "Browsers are evolving towards privacy-enhancing default referrer policies, to provide a good fallback when a website has no policy set," and testing in Chrome 84 suggested the breakage from the switch would be minimal.

Firefox followed roughly seven months later, trimming cross-origin referrers by default starting in Firefox 87. The W3C's Referrer Policy specification defines strict-origin-when-cross-origin as the user agent's default policy, so this isn't a temporary experiment. It's been the settled baseline across major browsers for years now.

The full list of Referrer-Policy values

Strict-origin-when-cross-origin sits in the middle of a spectrum. Knowing the full list helps you understand why it's the recommended middle ground rather than an arbitrary pick.

That last one deserves its own warning. MDN is blunt about it: Referrer-Policy: unsafe-url "will leak potentially-private information from HTTPS resource URLs to insecure origins," meaning it sends the full path and query string even when the request is headed to a plain HTTP destination. There's essentially no scenario on a modern site where that trade-off makes sense, and it's the single most common "leaky" flag a header checker will raise.

Which Referrer-Policy value is safest?

Strictly speaking, no-referrer is the safest value on the list. It sends nothing, ever, so there's nothing to leak. But "safest" and "recommended" aren't the same question, and this is where a lot of guides oversimplify.

Here's the decision framework I actually use when a client asks:

• Maximum privacy, no referral data needed: use no-referrer or Referrer-Policy same-origin if you still want full referrer detail for your own internal navigation but nothing leaving the site. You'll lose the ability to see which external sites send you traffic through the Referer header, though most analytics platforms have other ways to track that.
• Balanced default for most sites: use strict-origin-when-cross-origin. This is what the OWASP HTTP Headers Cheat Sheet recommends explicitly, noting that while modern browsers already default to it, declaring it protects visitors on older browsers too. It keeps full data for your own pages and trims everything else down to just the origin, which is why it works as a sensible default for most sites.
• Avoid entirely: Referrer-Policy unsafe-url. There's no beginner-friendly justification for shipping full URLs to every cross-origin destination, insecure ones included.

If your checker flagged a missing header, strict-origin-when-cross-origin is almost always the right fix. If it flagged a "leaky" value, you're probably running unsafe-url or no-referrer-when-downgrade somewhere in your config, possibly left over from an older tutorial or a CMS default.

Does Referrer-Policy affect Google Analytics referral data?

This is the question that brings most readers here, so let's answer it directly: no, setting Referrer-Policy to the browser default won't meaningfully change what Google Analytics sees, and it's not the usual cause of a "(direct)" traffic spike.

Here's why. Under strict-origin-when-cross-origin, a visitor arriving from another HTTPS site still sends the origin, the domain name, to your server. That's exactly what GA4 needs to attribute a session to a referring source.

What gets trimmed is the path and query string on that outbound leg, not the domain itself. GA4 still logs "referred by example.com," it just no longer sees which specific page on example.com the click came from. That's a loss of granularity, not a loss of attribution.

Where sites genuinely do see direct-traffic inflation is when someone sets a stricter value than the default on purpose, typically no-referrer or same-origin, without realizing the trade-off. Those values strip the referring domain entirely on cross-origin requests, and a visit with no Referer header at all gets bucketed as "(direct) / (none)" in GA4 because the platform has no signal to attribute it elsewhere.

If that's your situation, the fix isn't to loosen Referrer-Policy to unsafe-url. It's to reconsider whether you actually need that stricter setting, since the default already strips almost everything privacy-sensitive.

One more thing worth clearing up, because it comes up constantly in Google's own Analytics community forums: a referrer policy only touches the separate Referer header the browser sends automatically. It never touches the actual link a visitor clicks. UTM parameters, ?ref= codes, and affiliate IDs embedded in a URL survive regardless of what your Referrer-Policy header says, because those are part of the destination URL itself, not the referrer.

And if your real problem is self-referral noise, where your own domain shows up as a referrer to itself, Google Analytics has a purpose-built tool for that: the referral exclusion list under Admin, Data Streams, which lets you exclude up to 50 domains without touching your security headers at all.

How to set the Referrer-Policy header

Once you know which value you want, setting it is a one-line addition to your server config. On Apache, it looks like this:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

On nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

You can also set it per-page with a meta tag if you don't have server access, though the HTTP header is the more reliable route since it applies to every response, including non-HTML assets that a meta tag can't touch. If you'd rather not hand-write the header yourself, the securityheaders.tools generator builds the full block for Apache, nginx, Caddy, Cloudflare, Netlify, or Vercel in one pass, including Referrer-Policy alongside CSP, HSTS, and the rest of the set covered in our security headers explainer.

Quick recap

Run your site back through the securityheaders.tools checker once you've made the change. It'll confirm the header is present, correctly formed, and no longer flagged, and you'll see the rest of your grade alongside it rather than fixing one header in isolation. Referrer-Policy is only one piece of what a browser reveals about your visitors: if you also want to see which cookies and trackers a page sets, cookiecheck.tools runs a complementary scan of that side of the picture.

Frequently Asked Questions

What does Referrer-Policy do?

Referrer-Policy is an HTTP response header that controls how much of a page's URL the browser shares in the Referer header when it navigates away or loads a cross-origin resource. It can be set to reveal the full URL, just the domain, or nothing at all, and the choice affects both user privacy and how much referral detail your analytics tools can see.

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

It's the value that sends the full URL on same-origin requests, only the origin (domain, no path or query string) on cross-origin requests between two HTTPS sites, and nothing at all if the request downgrades from HTTPS to HTTP. It has been the default in Chrome since version 85 (August 2020), Firefox since version 87 (March 2021), and is defined as the user agent's default policy in the W3C Referrer Policy specification.

Does Referrer-Policy affect Google Analytics referral data?

Under the default strict-origin-when-cross-origin value, GA4 still receives the referring domain because that's the "origin" the policy is designed to preserve on cross-origin requests. It loses the specific page path, but not the source attribution itself. Direct-traffic inflation usually traces back to a stricter custom setting like no-referrer or same-origin, not to the browser default.

Which Referrer-Policy value is safest?

Technically, no-referrer is the safest because it sends nothing, but it also discards all referral data. For most sites, strict-origin-when-cross-origin is the recommended balance: it's what OWASP's HTTP Headers Cheat Sheet explicitly recommends and what modern browsers already default to. Avoid unsafe-url entirely, since MDN documents it as leaking full URLs even to insecure destinations.