Referrer-Policy Security Header | NOC.org

What Is Referrer-Policy?

Referrer-Policy is an HTTP security header that controls how much referrer information the browser includes when navigating from your site to another page or making requests to external resources. When a user clicks a link on your page, the browser typically sends a Referer header (the original HTTP specification misspelled "referrer") to the destination, indicating which page the user came from. This header can include the full URL, including the path, query parameters, and fragment.

While the Referer header is useful for analytics, debugging, and understanding traffic sources, it can also leak sensitive information. URLs often contain user IDs, session tokens, search queries, internal path structures, and other data that should not be shared with third parties. The Referrer-Policy header gives site owners control over exactly what information is shared, balancing privacy concerns with analytics needs.

The Eight Policy Values

no-referrer

Referrer-Policy: no-referrer

No referrer information is sent with any request, regardless of whether the navigation is same-origin or cross-origin, or whether the protocol changes. This is the most privacy-preserving option. The Referer header is completely omitted from all outgoing requests.

Use case: Sites handling highly sensitive data (healthcare, financial, legal) where no URL information should ever leak to external parties. The downside is that you lose all referrer data for analytics purposes, and third-party services you link to will not know the traffic came from your site.

no-referrer-when-downgrade

Referrer-Policy: no-referrer-when-downgrade

The full URL (origin, path, and query string) is sent as the referrer when navigating to a destination with an equally secure or more secure protocol (HTTPS to HTTPS, or HTTP to HTTP). However, no referrer is sent when navigating from a secure page to an insecure one (HTTPS to HTTP). This was the default browser behavior before modern browsers changed to strict-origin-when-cross-origin.

Use case: This policy protects against referrer leakage during protocol downgrades but still sends full URLs, including paths and query strings, to other HTTPS sites. This is generally too permissive for sites that care about privacy.

origin

Referrer-Policy: origin

Only the origin (scheme, host, and port) is sent as the referrer. The path and query string are stripped. For example, a request from https://example.com/private/page?token=abc would send only https://example.com/ as the referrer.

Use case: This provides a good balance when you want external sites to know traffic came from your domain without revealing specific page paths or query parameters. Useful for sites that need basic attribution without full URL disclosure.

origin-when-cross-origin

Referrer-Policy: origin-when-cross-origin

The full URL is sent for same-origin requests, but only the origin is sent for cross-origin requests. This lets your internal analytics and server logs see full referrer paths within your own domain while limiting what external sites receive to just the origin.

Use case: A practical choice for most web applications. Internal navigation preserves full URLs for analytics and debugging, while cross-origin requests only reveal that the traffic came from your domain.

same-origin

Referrer-Policy: same-origin

The full URL is sent for same-origin requests, but no referrer is sent at all for cross-origin requests. This is more restrictive than origin-when-cross-origin because cross-origin destinations receive no referrer information whatsoever.

Use case: Suitable for applications that need internal referrer data but want complete privacy from all external parties. Third-party sites will see the traffic as "direct" with no referrer.

strict-origin

Referrer-Policy: strict-origin

Similar to origin, but the referrer is only sent when the protocol security level stays the same or improves (HTTPS to HTTPS). No referrer is sent on protocol downgrade (HTTPS to HTTP). Only the origin is sent, never the path or query string.

Use case: A privacy-conscious choice that reveals your domain to other HTTPS sites but protects against referrer leakage to insecure HTTP sites.

strict-origin-when-cross-origin

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

This is the current default policy in all major browsers (Chrome, Firefox, Safari, Edge). It combines several behaviors:

• Same-origin requests: Full URL is sent as the referrer.
• Cross-origin requests with same security level: Only the origin is sent.
• Protocol downgrade (HTTPS to HTTP): No referrer is sent.

Use case: This is the recommended default for most websites. It provides a sensible balance between privacy and functionality. Your own site gets full referrer data, cross-origin HTTPS sites get your domain name, and insecure HTTP sites get nothing.

unsafe-url

Referrer-Policy: unsafe-url

The full URL (origin, path, and query string) is sent with every request, regardless of whether it is same-origin or cross-origin, and regardless of protocol changes. As the name suggests, this is the least safe option.

Use case: There are very few legitimate reasons to use unsafe-url. It might be considered in tightly controlled internal environments where all destinations are trusted, but even then, no-referrer-when-downgrade or origin-when-cross-origin would be safer choices. Using unsafe-url can expose session tokens, user IDs, and other sensitive URL parameters to every external resource your page loads.

Privacy Implications

The referrer information your site sends can reveal more than you might expect:

• Search queries: If your site has a search function and the query appears in the URL (/search?q=sensitive+topic), that query could be sent to every external resource on the results page.
• User identifiers: URLs containing user IDs, email addresses, or account numbers (/users/12345/settings) expose this information to third-party scripts, images, and linked sites.
• Authentication tokens: While tokens should never appear in URLs, they sometimes do in password reset links, OAuth flows, or API callbacks. Without a strict referrer policy, these tokens could leak.
• Internal structure: Full URL paths reveal your application's directory structure, technology stack, and admin panel locations to anyone you link to.
• Third-party trackers: External scripts, fonts, images, and analytics services loaded on your page all receive the referrer, giving them visibility into which pages your users visit.

Analytics Considerations

Tightening your referrer policy affects your analytics data and that of sites you link to:

• Your analytics: First-party analytics tools that run on your domain still receive full referrer data with most policies (except no-referrer), since they are same-origin requests.
• Third-party analytics: Services like Google Analytics typically use JavaScript tracking rather than relying on the Referer header, so they are less affected by referrer policy changes.
• Affiliate tracking: If you participate in affiliate programs that depend on referrer data, a very restrictive policy could affect attribution. Most modern affiliate programs use URL parameters or cookies instead, but verify with your partners.
• SEO impact: Search engines do not use the Referer header for ranking. Your referrer policy has no direct impact on SEO, though it can affect how sites you link to see your traffic in their analytics.

Server Configuration

Apache

# In .htaccess or virtual host config
Header always set Referrer-Policy "strict-origin-when-cross-origin"

# For more restrictive environments
Header always set Referrer-Policy "no-referrer"

Nginx

# In server block
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# For more restrictive environments
add_header Referrer-Policy "no-referrer" always;

HTML Meta Tag

You can also set the referrer policy using an HTML meta tag, which is useful when you do not have access to server configuration:

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

Per-Element Control

Individual HTML elements can override the page-level referrer policy using the referrerpolicy attribute:

<!-- Send no referrer for this specific link -->
<a href="https://external.com" referrerpolicy="no-referrer">External Link</a>

<!-- Send full URL for this specific image request -->
<img src="https://cdn.example.com/image.jpg" referrerpolicy="origin-when-cross-origin">

Per-element policies are useful when you need different referrer behavior for specific resources, such as sending no referrer for external links while allowing referrer data for your CDN.

Referrer-Policy and HTTPS

The interaction between referrer policy and HTTPS is important. Several policies treat protocol downgrades (HTTPS to HTTP) specially by withholding referrer data. This protects against scenarios where referrer data could be intercepted by a man-in-the-middle attacker on an insecure HTTP connection. If your site uses HSTS, the risk of protocol downgrade is already mitigated, but the referrer policy provides an additional safety net for links to external HTTP sites that you do not control.

Testing Your Referrer Policy

# Check the header with curl
curl -I https://example.com | grep -i referrer-policy

# Expected output
Referrer-Policy: strict-origin-when-cross-origin

You can also check referrer behavior in browser developer tools. Open the Network tab, click on a request to an external resource, and inspect the request headers to see what Referer value was sent.

Recommended Policy by Site Type

• General websites and blogs: strict-origin-when-cross-origin (the browser default, good for most sites)
• E-commerce sites: strict-origin-when-cross-origin or same-origin to prevent cart and product URLs from leaking
• Healthcare and financial applications: no-referrer or same-origin for maximum privacy
• Internal corporate applications: same-origin to keep all URL information within the application
• API services: no-referrer since API endpoints should not leak endpoint paths

Summary

Referrer-Policy is a security header that gives you control over what URL information browsers share when users navigate away from your site. The default browser policy of strict-origin-when-cross-origin is a good starting point for most sites, but you should evaluate your specific privacy requirements and adjust accordingly. Combined with other headers like HSTS and CSP, Referrer-Policy is an important component of a comprehensive security header strategy. See our security header configuration guide for implementation details.

Want to strengthen your site's security posture? Explore NOC.org plans to get started.