What is the Referer header
Before Referrer-Policy makes sense, you need to understand the Referer header itself. Browsers send it when a user follows a link or when a page loads another resource, and the value can reveal more than many teams expect: not just the origin, but sometimes the full path and query string of the page the user came from.
That can be useful for analytics and debugging, but it can also leak internal paths, campaign parameters, password-reset URLs, search terms, or application state to third parties. Referrer-Policy exists so you can decide how much of that context leaves the page instead of accepting the browser default blindly.
What Referrer-Policy controls
Referrer-Policy does one job: it decides how much referrer information the browser is allowed to send on each request. You can set it as an HTTP response header, with a <meta> tag for the page, or on specific elements and requests when you need tighter control around one link or one fetch.
The practical decision is not “do I want a referrer or no referrer?” It is “what should same-origin requests reveal, what should cross-origin requests reveal, and what should happen when a user moves from HTTPS to HTTP?” Once you frame it that way, the policy values become much easier to choose.
The 8 directive values
The eight standard values are no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, and unsafe-url. In real deployments, most teams spend their time comparing only a few of them: same-origin, strict-origin, and strict-origin-when-cross-origin.
The reason is simple. Those are the values that usually balance privacy with useful attribution. At the other extreme, unsafe-url is usually too permissive because it can send full paths and queries to other origins. At the stricter end, no-referrer is clear and safe, but it can remove too much context for analytics, support flows, or federated applications that legitimately depend on origin data.
Which to choose
For most modern public applications, strict-origin-when-cross-origin is the default starting point because it preserves the full referrer on same-origin navigation, trims cross-origin requests down to the origin, and drops the referrer on insecure downgrades. That usually gives teams the right privacy boundary without losing normal attribution.
Choose stricter values such as same-origin or no-referrer when the application handles sensitive internal paths, user identifiers, or query parameters that should never leave the origin. Choose looser values only when you can defend exactly why the downstream system needs the extra detail.
Privacy implications
Referrer-Policy is one of those headers that looks small until you think through the data it can leak. A full referrer can expose search strings, support-ticket IDs, password-reset flows, or internal product routes that were never meant for third parties.
That is why privacy teams and security teams both care about it. The question is not just whether the browser sends a referrer, but whether external analytics tags, CDNs, ad networks, or embedded content providers are learning more about the user's journey than they should. If you already review CSP or other web security headers, Referrer-Policy belongs in that same conversation.
How to fix or implement Referrer-Policy
Start by checking what the live site already sends. Many teams assume the app has no policy when in reality the browser default is doing the work, or a proxy is injecting a value nobody documented. Once you know the current state, choose the policy based on the most sensitive URLs your users can load, not the least sensitive.
The safest rollout is to pick a conservative value, verify that login flows, payment flows, analytics, and third-party integrations still behave as expected, and then make exceptions only where you can justify them. CyberFurl's security headers scan is useful here because it lets you review the live header instead of relying on framework defaults.
- 1
Measure the live response surface
Capture the real headers, certificate chain, and browser-facing behavior that define Referrer-Policy in production. Development assumptions are not enough for internet-facing posture.
- 2
Tighten policy without breaking real traffic
Roll out the control in a staged way, especially if it changes browser execution, redirects, or certificate trust. The goal is durable enforcement, not a one-time header screenshot.
- 3
Validate in browser and scanners
Tools to check your Referrer-Policy
Run the CyberFurl security headers scan to see the live Referrer-Policy value alongside the rest of the site's browser-facing headers. Then compare it with the broader web security headers feature page and related controls like CSP and HSTS so the header is reviewed as part of a real browser trust model, not as an isolated checklist item.
Further reading inside CyberFurl
- CyberFurl security headers scan
- See the web security headers feature
- Content Security Policy
- CyberFurl public security report
Standards and references
Frequently asked questions
What's the default if I don't set it?
In modern browsers the practical default is usually `strict-origin-when-cross-origin`. That means same-origin requests get the full referrer, cross-origin HTTPS requests usually get only the origin, and downgrades such as HTTPS to HTTP send nothing.
What's strict-origin-when-cross-origin?
It is the balanced default most teams want. Same-origin requests keep the full path, cross-origin requests send only the origin, and insecure downgrades drop the referrer entirely. You keep useful attribution without leaking full internal URLs to every external request.