Understanding the Referrer-Policy Header

How the Referrer-Policy header controls what information leaks to other sites through the Referer header.

Core Concept

The Referer header, sent automatically by browsers when navigating between pages, discloses the URL a user came from — sometimes including sensitive query parameters or paths.

The Referrer-Policy header lets a site control exactly how much of that URL is shared with the destination, balancing analytics usefulness against privacy leakage.

Insight: By default, browsers can leak a surprising amount of URL detail through the Referer header — Referrer-Policy exists specifically to rein that in.

Common Policy Values

Several policy values offer different trade-offs between privacy and referrer usefulness.

no-referrer — sends no referrer information at all
strict-origin-when-cross-origin — sends full URL same-origin, origin-only cross-origin
same-origin — sends full referrer only within the same site

Sensible Modern Default

strict-origin-when-cross-origin has become the browser default in recent years, balancing analytics utility against unnecessary data leakage.

Why Referrer Leakage Matters

URLs frequently contain more sensitive information than site owners realize.

Session tokens or reset links embedded in query parameters
Internal search terms revealing user intent or context
Account identifiers exposed through URL paths

Limitation: A password reset or magic-link URL containing a token in the query string can leak that token to any third-party resource loaded on the page if referrer policy isn't restricted.

Setting Policy at Different Levels

Referrer policy can be set globally via the HTTP header, or overridden per-link for finer control.

A meta tag or per-anchor referrerpolicy attribute allows exceptions where a specific link genuinely needs more or less referrer data than the site-wide default.

Layered Control

The HTTP header sets the baseline, while per-element referrerpolicy attributes allow fine-tuned exceptions without weakening the overall policy.

Choosing the Right Policy

The right value depends on how much a site relies on referrer data for analytics versus how sensitive its URLs are.

High-sensitivity applications → no-referrer or same-origin
General content sites → strict-origin-when-cross-origin
Sites needing cross-origin analytics → strict-origin

Insight: Defaulting to strict-origin-when-cross-origin is a reasonable baseline for most sites, tightened further only where URLs carry genuinely sensitive data.

Real-World Implementation

Referrer-Policy configuration is a quick, low-cost privacy improvement across production sites.

Authentication flows using no-referrer to avoid token leakage
Content sites balancing analytics needs against user privacy
Security audits flagging missing or overly permissive referrer policy

Because it's a single header with immediate effect, tightening referrer policy is one of the easiest security headers to deploy without breaking functionality.

Common Mistakes to Avoid

A few common mistakes lead to unnecessary referrer data leakage.

Leaving Referrer-Policy unset and relying entirely on browser defaults.
Overlooking sensitive query parameters like tokens that end up leaked through referrers.
Applying an overly permissive policy without considering the site's actual URL sensitivity.
Failing to set a per-link override for the rare cases that genuinely need different behavior.
Assuming referrer policy has no real privacy or security implications.
Overlooking that Referrer-Policy set via meta tag can be overridden by a stricter HTTP header.
Assuming referrer policy has no impact on analytics accuracy.
Failing to test referrer behavior across both internal and external navigation.
Overlooking that some third-party integrations explicitly require referrer data to function correctly.
Assuming referrer policy interacts identically with all types of outbound links.
Failing to test referrer behavior specifically for links opened in a new tab.
Overlooking that referrer policy defaults have changed across browser versions over time.

Best Practices Checklist

These practices help minimize unnecessary referrer data leakage.

Set an explicit Referrer-Policy rather than relying entirely on browser defaults.
Avoid embedding sensitive tokens directly in URLs where referrer leakage is a risk.
Use stricter values like no-referrer for high-sensitivity authentication flows.
Apply per-link referrerpolicy overrides only where genuinely necessary.
Review referrer policy periodically as URL structures and third-party integrations evolve.
Understand how meta tag and HTTP header referrer policies interact and which takes precedence.
Account for referrer policy's impact when reviewing analytics data accuracy.
Test referrer behavior explicitly for both internal and external navigation scenarios.
Verify whether any third-party integrations genuinely require referrer data before restricting it fully.
Test referrer policy behavior across different link types, including those opening in a new tab.
Document any exceptions where a looser referrer policy is intentionally applied for specific links.
Set referrer policy explicitly rather than relying on evolving browser default behavior.

Frequently Asked Questions

Frequently asked questions about the Referrer-Policy header.

What information can leak through the Referer header?

The URL a user navigated from, which can include sensitive query parameters, session tokens, or internal search terms if not properly restricted.

What's a sensible default Referrer-Policy value?

strict-origin-when-cross-origin has become the common browser default, balancing analytics usefulness against unnecessary data leakage.

Can a password reset link leak its token through referrer data?

Yes — if referrer policy isn't restricted, a token embedded in a reset URL's query string can leak to any third-party resource loaded on the page.

Can referrer policy be set differently for specific links?

Yes — a per-element referrerpolicy attribute allows exceptions without weakening the overall site-wide policy set via the HTTP header.

Does tightening referrer policy break analytics?

It can reduce certain cross-origin referrer data, but strict-origin-when-cross-origin generally preserves enough for standard analytics purposes.

Which takes precedence, a meta tag or HTTP header Referrer-Policy?

Generally the more restrictive of the two applies, though exact behavior can vary slightly by browser implementation.

Can referrer policy affect analytics accuracy?

Yes — a restrictive policy can reduce the referrer information available to analytics tools, affecting traffic source attribution.

Should referrer behavior be tested for both internal and external links?

Yes — behavior can differ meaningfully between same-origin and cross-origin navigation, making both worth verifying.

Do some integrations break if referrer data is too restricted?

Yes — certain analytics or attribution tools depend on referrer data, making a blanket no-referrer policy potentially disruptive without exceptions.

Does referrer policy behave the same for links opening in a new tab?

Generally consistent, but it's still worth testing explicitly since some edge cases in browser handling can differ.

Have default referrer policies changed across browser versions?

Yes — defaults have shifted toward more privacy-protective behavior over time, making explicit configuration more reliable than assuming a specific default.

Check Referrer Policy

Run a security headers scan to see a domain's current Referrer-Policy configuration.

Launch Tool →