Referrer-Policy: Controlling What You Leak
Every time a visitor clicks a link off your site, their browser can tell the destination exactly which of your pages they came from — sometimes including query strings full of sensitive data. The Referrer-Policy header lets you decide how much of that information leaves your site.
The short version
Set Referrer-Policy: strict-origin-when-cross-origin. It sends the full URL within your own site, only the bare origin to other HTTPS sites, and nothing at all when downgrading to HTTP. It is a sensible privacy default and is what most modern browsers already use when you send nothing. Check your current value with our headers check.
What the Referer header leaks
When a browser follows a link or loads a resource, it typically sends a Referer header (the historical misspelling is baked into the standard) naming the page the request came from. That sounds harmless, but URLs often carry more than a path. A password-reset link, a search query, an account ID or a session token in the query string can all end up disclosed to whichever third party the user clicks through to — and to every analytics or ad script embedded on that destination.
The Referrer-Policy header controls exactly how much of the URL, if any, is included in that header for links, images, scripts and other outbound requests.
The policy values
| Value | What it sends |
|---|---|
no-referrer | Nothing, ever. Maximum privacy, but breaks analytics that rely on referrers. |
same-origin | Full URL to your own site, nothing to any other site. |
strict-origin | Only the origin (scheme + host), and only when security is not downgraded. |
strict-origin-when-cross-origin | Full URL within your site, origin only to other sites, nothing on HTTPS→HTTP. |
no-referrer-when-downgrade | Full URL except when moving from HTTPS to HTTP. The old default; leaks more. |
unsafe-url | Always sends the full URL everywhere. Avoid — the name is a warning. |
“Origin” here means just https://example.com with no path or query — enough for a destination to know traffic came from you, without exposing the specific page or its parameters.
Why strict-origin-when-cross-origin is the sensible default
This value strikes the balance most sites want. Internal navigation still gets the full URL, so your own analytics and relative logic keep working. Links to other sites reveal only your origin, so query-string secrets never leak across the boundary. And if a user moves from an HTTPS page to an insecure HTTP one, no referrer is sent at all, preventing sensitive data from crossing an unencrypted connection. It is now the default many browsers apply even without the header, but setting it explicitly guarantees consistent behaviour everywhere.
Setting the header
Referrer-Policy: strict-origin-when-cross-originOn Apache add Header always set Referrer-Policy "strict-origin-when-cross-origin"; on Nginx use add_header Referrer-Policy "strict-origin-when-cross-origin" always;. You can also override the policy for a single link with the referrerpolicy attribute or a rel="noreferrer":
<a href="https://example.org" rel="noreferrer">External link</a>Where it fits
Referrer-Policy is a low-risk, quick win on the wider security headers checklist — unlike HSTS or CSP, it will not break your site if you get it slightly wrong. Once you have set it, run a scan to confirm the value is being sent on every response.
Frequently asked questions
Will this hurt my analytics?
Not with the recommended value. strict-origin-when-cross-origin still passes full referrer data within your own site and the origin to others, so most analytics setups keep working. Only no-referrer removes the data entirely.
Is Referer really spelled wrong?
Yes. The HTTP header has been misspelled “Referer” since the early web and the spelling was never fixed for compatibility. The newer Referrer-Policy header uses the correct spelling.
What happens if I set no header at all?
Most current browsers fall back to strict-origin-when-cross-origin anyway, but older browsers may leak more. Setting it explicitly gives you consistent, predictable behaviour.
Related guides
HTTP Security Headers: The Complete Checklist
Every important HTTP security header explained, what it protects against, and a copy-paste starting configuration.
Read →HTTP Security HeadersHSTS Explained: Strict-Transport-Security Done Right
How HSTS forces HTTPS, what the preload list means, and how to roll it out without locking yourself out.
Read →HTTP Security HeadersContent Security Policy (CSP) for Beginners
How CSP stops cross-site scripting, why it is hard to get right, and a safe way to deploy your first policy.
Read →Check your site against this guide
Run a free ScanOpsPro scan and see how your site handles the fundamentals.
Run a free scan