Every time someone clicks a link from your site to another site, their browser sends information about where they came from. The destination site learns the URL that referred the visitor. For simple cases, this is harmless. For privacy-conscious cases or cases involving sensitive URLs, the default behavior leaks information that should stay private.
Referrer-Policy is the security header that controls what information gets sent in referrer headers. The configuration affects user privacy, can prevent specific information leaks, and is increasingly relevant as privacy expectations grow.
This piece covers what referrer information actually leaks, why it matters, the options Referrer-Policy provides, and how to configure it appropriately.
What Referrer Information Reveals
The default browser behavior sends more information than people often realize.
The Referer Header
When a browser navigates from one page to another, it sends a Referer header with the request. The header contains the URL of the previous page.
Note the spelling. The header was misspelled in the original HTTP specification (“Referer” instead of “Referrer”) and the misspelling stuck. The Referrer-Policy header uses the correct spelling. The HTTP header it controls keeps the misspelling.
What Default Behavior Sends
Without Referrer-Policy configured, browsers send the full URL of the source page. This includes:
The domain (example.com).
The path (/products/widget).
Query parameters (?id=12345).
Sometimes URL fragments.
The full URL goes to the destination site, where it can be logged, analyzed, or potentially leaked further.
Why This Information Can Be Sensitive
URLs sometimes contain sensitive information:
Session tokens or authentication codes in query parameters.
User identifiers in paths.
Search queries in parameters.
Source pages that reveal user activity (admin pages, account pages, sensitive content).
Pages that should be private (membership areas, paid content URLs).
When users navigate from these pages to external sites, the URL of the sensitive page gets transmitted to the destination.
Privacy Implications
For most casual browsing, this is not a major concern. But for users with privacy needs or sites with sensitive URL structures, the leakage matters.
Healthcare sites where the URL might reveal a condition. Government sites where the source URL might reveal interest in specific information. Sites that include user identifiers in URLs.
Each of these has reason to control referrer information.
How Referrer-Policy Works
The header controls what gets sent in the Referer header.
The Policy Values
Referrer-Policy supports several values:
no-referrer sends nothing. The Referer header is omitted entirely.
no-referrer-when-downgrade sends full referrer to same-protocol destinations (HTTPS to HTTPS) but nothing for HTTPS to HTTP. This was the default behavior before Referrer-Policy.
origin sends only the origin (scheme, host, port) but not the path or query parameters.
origin-when-cross-origin sends full referrer for same-origin navigation, just the origin for cross-origin.
same-origin sends full referrer for same-origin requests, nothing for cross-origin.
strict-origin sends only origin for HTTPS to HTTPS, nothing for HTTPS to HTTP.
strict-origin-when-cross-origin sends full referrer for same-origin, just origin for cross-origin HTTPS to HTTPS, nothing for HTTPS to HTTP.
unsafe-url sends full referrer always. Worst for privacy.
The Default
Modern browsers default to strict-origin-when-cross-origin for sites without explicit Referrer-Policy. This is a reasonable balance of privacy and functionality.
But explicit policies show intent and ensure consistent behavior across browsers.
Recommended Default
For most sites, strict-origin-when-cross-origin is the right choice. It:
Sends full referrer to your own site (useful for analytics).
Sends only the origin to other HTTPS sites (some attribution without leaking paths).
Sends nothing for HTTPS to HTTP (prevents leakage to insecure destinations).
This balances functionality with privacy reasonably.
When to Use Stricter Policies
Some situations call for more restrictive referrer policies.
Healthcare Sites
Health-related URLs can reveal sensitive information about users. Stricter policies (no-referrer or same-origin) prevent leakage of health-related URLs to external sites.
Government & Legal Sites
URLs accessed by users might reveal their interests, concerns, or activities in ways that should remain private. Stricter policies protect this information.
Membership & Paid Content
Sites with restricted content sometimes use URL patterns that reveal what content exists. Stricter referrer policies prevent these URLs from leaking when users click external links.
Sites With Sensitive User Identifiers
If your URLs contain user identifiers that could be used to track users across sites, restrictive referrer policies prevent the identifiers from spreading.
High-Security Applications
Applications dealing with banking, security tokens, or other sensitive operations should use strict policies as part of comprehensive privacy and security configuration.
When to Allow More Information
Some situations need more referrer information for legitimate reasons.
Analytics Across Sites
If you run analytics that need to identify referral sources from your site to partner sites, sending more referrer information helps.
But this is usually solved through other means (UTM parameters, dedicated tracking links) rather than relying on referrer information.
Affiliate Networks
Affiliate marketing sometimes relies on referrer information to track which site sent a customer. Restrictive policies can break attribution.
The fix is usually to use dedicated affiliate tracking that does not depend on referrer headers.
CDN & Asset Loading
Some CDNs use referrer headers to control access to content. Pictures behind paywalls might check the referrer to ensure the request comes from an authorized page.
For these cases, the referrer policy needs to allow enough information for the CDN to work.
How to Configure Referrer-Policy
The implementation matches other security headers.
Apache
Add to .htaccess or virtual host configuration:
Header set Referrer-Policy “strict-origin-when-cross-origin”
Nginx
Add to server configuration:
add_header Referrer-Policy “strict-origin-when-cross-origin” always;
WordPress
Security plugins handle this. The same plugins that handle other security headers (Sucuri, iThemes Security, Wordfence) include Referrer-Policy options.
Cloudflare
Cloudflare supports custom headers through Transform Rules.
Meta Tag Alternative
For situations where you cannot add HTTP headers, the policy can be set in a meta tag:
<meta name=”referrer” content=”strict-origin-when-cross-origin”>
The HTTP header is preferred when possible. The meta tag works as fallback.
Per-Link Control
Individual links can have their own referrer policy through the referrerpolicy attribute:
<a href=”https://example.com” referrerpolicy=”no-referrer”>Link</a>
Useful for specific cases where you want different behavior for specific links.
Testing Your Configuration
After setting Referrer-Policy, verify it works.
Browser Developer Tools
Navigate from your site to an external site. Look at the request to the external site. Check the Referer header value. Compare to what your policy should allow.
Security Header Scanners
Mozilla Observatory and Security Headers both check for Referrer-Policy as part of their scans.
Cross-Browser Testing
Different browsers may handle some edge cases differently. Test in multiple browsers to confirm consistent behavior.
Common Configuration Mistakes
People stumble in predictable ways.
Not Setting It
The most common mistake. Without explicit Referrer-Policy, browsers use their defaults, which may not match your actual needs.
Setting It Too Restrictively
Overly strict policies can break analytics, affiliate tracking, and some legitimate cross-site functionality. The right policy balances privacy with functionality.
Using Deprecated Values
Some old documentation references values that are no longer supported. Use current values: no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url.
Inconsistent Policy Across Site
Different pages with different policies create confusing behavior. Pick one policy and apply it consistently.
Trusting Referer for Security
Some sites use Referer headers for security checks. This is unreliable. Referer can be missing, modified, or absent depending on browser settings and Referrer-Policy.
Do not rely on Referer for authorization decisions.
Privacy Considerations Beyond This Header
Referrer-Policy is one piece of privacy configuration.
Cookie Settings
Cookies marked as SameSite limit cross-site tracking. Use SameSite=Strict or SameSite=Lax for session cookies.
Tracking Pixels & Scripts
Third-party tracking can leak information regardless of Referrer-Policy. Audit what trackers your site uses.
Form Submissions to External Sites
Forms that submit to external sites pass data directly to those sites. Referrer-Policy does not affect form submissions.
Browser Fingerprinting
Beyond referrer information, browsers leak other information that can be used for tracking. Comprehensive privacy requires considering these other vectors.
Setting Policies for Specific Pages
Sometimes different pages need different policies.
Sensitive Pages
Account pages, admin pages, and other sensitive pages might warrant stricter policies than general content pages.
Marketing Pages
Marketing landing pages with attribution needs might use more permissive policies.
How to Set Different Policies
The HTTP header approach sets one policy for the response. Different pages need different responses.
The meta tag approach lets each page set its own policy.
Per-link policies let specific links override the page policy.
The right combination depends on the specific needs.
Closing Thoughts on Referrer Configuration
Referrer-Policy is one of those security and privacy headers that fits into broader configuration. The implementation is straightforward. The default value of strict-origin-when-cross-origin works for most sites.
For most sites, the right approach is to set strict-origin-when-cross-origin as the site-wide policy and adjust per-page or per-link when specific needs arise. This balances privacy with functionality.
The header is most valuable for sites where URLs contain sensitive information. Healthcare, financial, government, membership. For these, careful configuration protects user privacy beyond the defaults.
For general content sites, the difference between the default policy and an explicit one is minimal in practice. But setting the header explicitly shows attention to security configuration and ensures consistent behavior.
If your site has not been configured with Referrer-Policy, this is a small but worthwhile addition. The work is minimal. The privacy benefit is real for users navigating from your site to others.
Sites that take privacy seriously include Referrer-Policy as part of their standard configuration. The absence of the header is usually a sign of incomplete attention to privacy and security rather than a deliberate decision. Make it part of your standard setup, and one more aspect of user privacy is handled appropriately. The configuration takes minutes. The protection persists across all users who interact with your site.
