Referrer-Policy Header: What It Does and How to Set It Correctly

Run a free check — 60 seconds

For example, if a user on https://example.com/dashboard/settings?user=john clicks a link to https://external-site.com, the browser sends:

That external site now knows: - The user came from example.com - They were on the dashboard settings page - The URL contains a username parameter

This is the referrer leakage problem.

Why Referrer Leakage Is a Privacy Problem

Referrer leakage exposes sensitive information in several ways:

### URL Parameters Many applications put sensitive data in URLs: - Session tokens: ?token=abc123 - User identifiers: ?user_id=42 - Search queries: ?q=medical+symptoms - API keys: ?key=sk_live_xxx - Password reset tokens: /reset?token=secret

When these URLs appear in the Referer header, external sites receive data they were never intended to see.

### Internal Structure Exposure Even without sensitive parameters, referrer URLs reveal: - Your application's URL structure and routing patterns - Internal page names (admin panels, internal tools) - User workflow patterns (which pages they visit in sequence) - Technology indicators (e.g., /wp-admin/ reveals WordPress)

### Real-World Consequences - Healthcare sites leaking medical search queries to advertisers - Banking sites leaking account numbers in URL parameters - HR platforms leaking employee IDs to third-party analytics - [E-commerce sites](https://zeriflow.com/blog/pci-dss-website-compliance-guide) leaking order details to social media pixels

### Third-Party Scripts It's not just external links. Every third-party resource your page loads (analytics scripts, ad pixels, social media widgets, CDN resources) can read the current page URL. This means dozens of companies may know which pages your users visit.

Referrer-Policy Directives Explained

The Referrer-Policy header lets you control exactly how much referrer information the browser shares. Here are all eight possible values:

### no-referrer Never send the Referer header. Maximum privacy.

### no-referrer-when-downgrade Send the full URL for same-protocol requests. Don't send anything when navigating from HTTPS to HTTP. This was the default browser behavior before 2020.

### origin Send only the origin (scheme + host + port), never the path or query string.

### origin-when-cross-origin Send the full URL for same-origin requests. Send only the origin for cross-origin requests.

### same-origin Send the full URL for same-origin requests. Don't send anything for cross-origin requests.

### strict-origin Send only the origin for same-protocol requests. Don't send anything on downgrade (HTTPS → HTTP).

### strict-origin-when-cross-origin The most balanced option and the current browser default. Full URL for same-origin, origin-only for cross-origin (same protocol), nothing on downgrade.

### unsafe-url Always send the full URL, even on downgrades. Never use this — it defeats the purpose of having a policy.

Which Value Should You Use?

For most websites, here's the decision:

Our recommendation: Start with strict-origin-when-cross-origin. It's the best balance between privacy and functionality. It prevents URL parameter leakage to external sites while still allowing your analytics to see internal navigation paths.

If you handle particularly sensitive data (health, finance, legal), consider no-referrer or same-origin.

Setting Referrer-Policy

Nginx

Apache

Next.js

In next.config.js:

Express.js

Or with the helmet middleware:

HTML-Level Referrer Control

Beyond the HTTP header, you can set referrer policy at the HTML level:

Meta Tag (Page-Wide)

Per-Link Control

Per-Element Control

rel="noreferrer" on Links

This is equivalent to referrerpolicy="no-referrer" and also implies rel="noopener", which prevents the linked page from accessing window.opener.

Priority order: Per-element attribute > <meta> tag > HTTP header > browser default.

Test Your Implementation

### Browser DevTools 1. Open DevTools (F12) → Network tab 2. Click on any request to an external resource 3. Look at the Request Headers section for Referer 4. Verify it matches your expected policy behavior

Curl Check

### Full Scan Run your site through ZeriFlow to verify your Referrer-Policy header is set correctly alongside all other security headers.

Impact on Analytics

Changing your Referrer-Policy will affect analytics data — both yours and others':

### Your Analytics - no-referrer or same-origin will break referrer tracking for external links pointing to your site. You won't see which sites send you traffic in Google Analytics or similar tools. - strict-origin-when-cross-origin preserves origin-level referrer data (you'll see https://example.com but not the full path), which is sufficient for most analytics needs.

### Others' Analytics - Sites you link to will receive less referrer data, which may affect their analytics - This is generally considered good practice — you're protecting your users' privacy

### UTM Parameters Still Work If you use UTM parameters for campaign tracking (?utm_source=newsletter), they work regardless of Referrer-Policy because they're on the destination URL, not the referrer.

### Recommendation Use strict-origin-when-cross-origin to maintain useful analytics while protecting user privacy. If you switch to no-referrer, rely on UTM parameters for campaign tracking.

Further Reading

• MDN Web Docs — Referrer-Policy

<!-- zf-internal-links -->