Referrer-Policy Header Best Practices for Modern Sites

The Referrer-Policy header is one of those small configuration choices that quietly shapes both your users' privacy and your analytics accuracy. Get it wrong and you leak full URLs (with query strings, tokens, and internal paths) to every third-party script, ad network, and outbound link. Get it too restrictive and you'll break attribution, affiliate tracking, and legitimate referrer-based access control.

Here's how to choose, set, and verify a Referrer-Policy that fits a real production site.

What the Referrer-Policy header actually controls

When a browser makes a request triggered by your page — a navigation, an image load, a fetch, a form submission — it can send a Referer header telling the destination where the request originated. Referrer-Policy controls how much of that origin URL is sent.

The trade-offs come down to three axes:

• Cross-origin vs same-origin — do you want different behavior for internal navigation vs outbound links?
• HTTPS to HTTP downgrade — should the referrer be stripped when going from a secure to insecure page?
• Full URL vs origin only — send the entire URL with path and query, or just https://example.com?

The eight directives, ranked by real-world usefulness

1. strict-origin-when-cross-origin (recommended default)

This is the modern browser default and the right starting point for most sites. It sends:

• The full URL on same-origin requests
• Only the origin on cross-origin HTTPS requests
• Nothing on HTTPS-to-HTTP downgrades

You keep internal analytics intact, you give outbound destinations enough to track high-level attribution, and you never leak paths to insecure endpoints.

2. no-referrer

Strips the header entirely on every request. Use this on admin panels, banking dashboards, healthcare portals, or any page where the URL itself might contain sensitive identifiers (password reset tokens, session IDs in query strings, user IDs in paths).

3. same-origin

Full URL for same-origin requests, nothing for cross-origin. A solid pick for internal tools and SaaS dashboards where you don't want outbound services to see anything at all but still want internal logging.

4. origin

Sends only the origin, always. Useful if you need outbound services to know which site sent traffic but you don't want to expose paths anywhere.

5. strict-origin

Like origin, but drops the header on HTTPS-to-HTTP downgrades. Reasonable for sites that aggressively limit referrer data but still want some attribution.

6. origin-when-cross-origin

Full URL same-origin, origin only cross-origin — but it does not protect against HTTPS-to-HTTP downgrades. Prefer strict-origin-when-cross-origin instead.

7. no-referrer-when-downgrade

The legacy default. Sends full URL except on downgrades. Leaks paths to every third party. Avoid unless you have a specific legacy compatibility need.

8. unsafe-url

Sends the full URL on every request, regardless of protocol. The name is a warning. Don't use this on production sites.

Setting the header correctly

Via HTTP response header

This is the canonical approach and applies to all resources served by the origin:

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

Nginx:

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

Apache:

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

Express / Node.js:

app.use((req, res, next) => {
  res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');
  next();
});

Via meta tag (fallback)

<meta name="referrer" content="strict-origin-when-cross-origin">

Use this only when you can't set HTTP headers (static hosting without header control). The HTTP header takes precedence and applies to all requests, including those triggered before the HTML is fully parsed.

Per-element overrides

You can tighten the policy on specific links or images:

<a href="https://partner.example" referrerpolicy="no-referrer">Partner</a>

This is helpful for individual outbound links to sensitive destinations without changing your site-wide policy.

Best practices checklist

1. Set a header at the edge — CDN or reverse proxy, so it applies before requests even reach your app servers.
2. Default to strict-origin-when-cross-origin for marketing sites, blogs, and most product apps.
3. Use no-referrer on authenticated areas where URLs may contain tokens, IDs, or other secrets.
4. Never put secrets in URLs in the first place — the Referrer-Policy is defense in depth, not your primary protection.
5. Audit query strings for PII: email addresses, names, internal user IDs. If they're there, tighten the policy and refactor.
6. Pair with a Content-Security-Policy. CSP can include a referrer directive, but the standalone header is more widely supported and clearer.
7. Don't rely on the browser default — set the header explicitly so behavior is consistent across user agents and proxies.
8. Test downgrade scenarios if any part of your stack still serves HTTP.

Common mistakes worth avoiding

• Setting it once in HTML but not on API responses. Fetch requests respect the policy that was active when the request was made; inconsistent headers across endpoints cause confusing leaks.
• Choosing no-referrer globally and then wondering why affiliate revenue dropped. Many partner networks rely on the referrer for attribution.
• Trusting the meta tag alone. Resources requested very early in page load (preloads, early script tags) may use the browser default before the meta tag is parsed.
• Forgetting subdomains. A request from app.example.com to api.example.com is cross-origin. If you want full URLs there, use same-origin won't help — you'd need to architect around it or accept origin-only.
• Conflicting headers from middleware. Multiple layers (framework, reverse proxy, CDN) each setting their own Referrer-Policy leads to whichever one runs last winning. Pick one source of truth.

Verify before you ship

After deploying, confirm the header is actually being sent — and that no upstream proxy is stripping or overriding it. The fastest way is to inspect the live response headers. AXOX Hub's HTTP Header Checker shows you every response header from any public URL, including Referrer-Policy, so you can verify the value matches what you configured and that it's consistent across paths (root, asset URLs, API endpoints).

Spot-check the obvious candidates: homepage, a logged-out marketing page, a login page, an API response, and a static asset. If any of them differ, you've found a misconfigured middleware layer.

Run your domain through the free HTTP Header Checker at AXOX Hub to confirm your Referrer-Policy is set the way you intended.