Referrer-Policy security response

What it does

Referrer-Policy controls how much of your page's URL is shared in the Referer header when users navigate to other sites, or when your page loads resources from other origins. Without a policy, browsers send the full URL — including paths and query strings that may contain sensitive data like search terms, user IDs, or authentication tokens.

Syntax

Referrer-Policy: <policy>

Example:

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

Policy values

Key:

• "Full URL" = https://example.com/path?query=value
• "Origin only" = https://example.com
• "Nothing" = no Referer header sent

The browser default

Modern browsers default to strict-origin-when-cross-origin when no policy is set:

• Same-origin: sends full URL (useful for analytics)
• Cross-origin HTTPS: sends origin only (privacy-preserving)
• Downgrade to HTTP: sends nothing (security — don't leak HTTPS URLs over HTTP)

This is a sensible default. Setting your policy explicitly to strict-origin-when-cross-origin is equivalent to the default but documents your intent.

What leaks without a policy

Consider a URL like:

https://app.example.com/users/42/reset-password?token=abc123xyz

If a user on this page clicks an external link (to a third-party CSS, a social share button, an analytics pixel, or just an outbound link), the external server receives:

Referer: https://app.example.com/users/42/reset-password?token=abc123xyz

The password reset token is now in that third party's access log. With Referrer-Policy: strict-origin-when-cross-origin, they'd only see:

Referer: https://app.example.com

Other sensitive URL patterns to protect: /admin/, /checkout?cart=..., /search?q=medical+condition, /profile/username.

Choosing a policy

For most sites:

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

Good balance — full URL within your own site (good for internal analytics), origin only to external HTTPS sites, nothing to HTTP sites.

For maximum privacy:

Referrer-Policy: no-referrer

Nothing is sent anywhere. External sites and your own analytics won't see any referrer data. Some analytics tools will show all traffic as "direct."

If you need internal analytics but maximum external privacy:

Referrer-Policy: same-origin

Full URL for same-origin requests; nothing for any cross-origin request.

Avoid:

Referrer-Policy: unsafe-url

Sends the full URL everywhere, including to HTTP sites. Only appropriate if you explicitly need third parties to receive full URLs and have audited the privacy implications.

Setting policy at multiple levels

Referrer-Policy can be set at three levels — each narrower level overrides the broader one:

HTTP header (applies to the whole page):

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

HTML meta tag (applies to the whole page):

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

Per-element attribute (applies to a specific link or resource):

<a href="https://external.com" referrerpolicy="no-referrer">Click me</a>
<img src="https://cdn.example.com/image.jpg" referrerpolicy="origin">

This lets you set a baseline policy while allowing specific elements to be more or less restrictive.

How it interacts with the Referer header

Referrer-Policy controls what value appears in the Referer header on outbound requests from your page. The Referer header is what other sites receive; Referrer-Policy is your control over it.

Note the spelling difference: the HTTP header is Referer (historical typo, one 'r'); the policy header is Referrer-Policy (correct spelling). This inconsistency has existed since HTTP/1.0 and will never be fixed.

Common mistakes and gotchas

Setting no-referrer site-wide and breaking analytics. Without referrer data, all traffic appears as direct in your analytics. Your own internal page-to-page navigation won't show the previous page. Consider same-origin if internal analytics matter.

Not setting any policy and trusting the browser default. The browser default is reasonable, but explicit is better — document your intent, and be protected if browsers change their defaults.

Using unsafe-url for any reason. The only reason to use this is if a third-party integration explicitly requires full URLs, which is a red flag. Audit why they need full URLs before complying.

Real-world examples

Standard secure site:

HTTP/1.1 200 OK
Referrer-Policy: strict-origin-when-cross-origin

Healthcare or financial application:

HTTP/1.1 200 OK
Referrer-Policy: no-referrer

Specific link that should send no referrer:

<a href="https://partner.com/signup" referrerpolicy="no-referrer">
  Join our partner
</a>

FAQ

Does Referrer-Policy affect what Referer header my server receives?

No — Referrer-Policy only controls what your page sends when navigating away or loading resources. It doesn't affect the Referer header that other sites send when linking to you. To see what referrer external sites are sending you, check your server logs.

Should I set Referrer-Policy on API responses?

API responses consumed programmatically don't trigger browser navigation, so Referrer-Policy has no effect on them. Set it on HTML page responses.

Is there a privacy difference between origin and strict-origin?

Yes. origin sends the origin on both HTTPS→HTTPS and HTTPS→HTTP transitions. strict-origin sends nothing on HTTPS→HTTP. strict-origin is more privacy-preserving because it avoids leaking any information (even just your domain name) to insecure HTTP destinations.

Fun fact

The Referer header's famous typo — missing the second 'r' in "referrer" — was a mistake in the original HTTP/1.0 specification written by Tim Berners-Lee in 1996. By the time anyone noticed, it was already in implementations everywhere. The HTTP spec has preserved the typo ever since. When the W3C created Referrer-Policy in 2014, they used the correct spelling — resulting in an HTTP ecosystem where Referer (one 'r') and Referrer-Policy (two 'r's) coexist as the world's most documented and irreversible typo in a technical standard.