Referrer Policy

What Is the Referrer-Policy Header?

The Referrer-Policy HTTP response header controls how much referrer information--sent via the traditional Referer header--should be included with requests initiated from your web pages. When users navigate from one website to another or when a page loads external resources like images, scripts, or fonts, browsers transmit information about the originating page through the HTTP Referer header.

Without proper controls, this can inadvertently leak sensitive information such as session tokens, password reset links, or private page identifiers to third-party services. The Referrer-Policy header provides web developers with fine-grained control over this behavior.

From a user-centered design perspective, Referrer-Policy directly impacts trust. Users expect their browsing activity to remain private, yet the default referrer behavior can expose their navigation patterns to external parties. When you implement thoughtful referrer policies, you're demonstrating respect for user privacy--a key factor in building trust and credibility with your audience. Moreover, sensitive information in URLs represents a significant privacy risk. Consider password reset tokens, private document IDs, or search queries containing personal information. Without proper referrer controls, this data could be logged by analytics services, advertising networks, or third-party resources, creating privacy compliance challenges and potential security vulnerabilities.

The OWASP HTTP Headers Security Cheat Sheet recommends implementing referrer policy as a core component of HTTP security headers. This recommendation reflects real-world privacy implications: referrer information can reveal internal site structure, administrative paths, and user behavior patterns that competitors or malicious actors could exploit. For organizations in regulated industries, uncontrolled referrer leakage may violate privacy compliance requirements such as GDPR, CCPA, or PIPEDA.

Implementing proper HTTP security headers is a fundamental aspect of professional web development services that prioritize both functionality and user privacy.

Understanding the Referer Header

The HTTP Referer header (note the historical misspelling) has been part of the web since its earliest days. It serves legitimate purposes--analytics systems use it to understand traffic sources, servers use it for logging and debugging--but creates privacy and security risks.

When a browser sends a request with a Referer header, it includes the complete URL of the referring page, including query parameters. For a URL like https://example.com/products?category=electronics&user_id=12345, the entire path and query string would be transmitted.

Modern browsers have progressively tightened default referrer behavior. Today, most browsers send only the origin (scheme, host, and port) by default when navigating to cross-origin destinations, while sending full URLs for same-origin requests. However, relying on browser defaults creates inconsistent behavior across user populations with different browsers and versions.

The privacy implications extend beyond individual user data. Referrer information can reveal internal site structure, administrative paths, and user behavior patterns that competitors or malicious actors could exploit. For organizations in regulated industries, uncontrolled referrer leakage may violate privacy compliance requirements.

The Privacy-Security Tradeoff

Implementing stricter referrer policies enhances privacy but can impact legitimate functionality. Analytics systems may lose referral source data, payment processors may not receive expected referrer information, and some third-party integrations may require full URL referrers to function correctly. Balancing these competing concerns requires thoughtful policy selection based on your specific use cases and user expectations. Understanding how referrer data affects your SEO performance helps inform the right balance between privacy and analytics needs.

Referrer Policy Directives

The Referrer-Policy specification defines eight distinct directives, each providing different levels of referrer information sharing. Understanding these options allows you to choose the appropriate policy for each context.

no-referrer

The most restrictive option, no-referrer, completely eliminates the Referer header from all requests. No referrer information whatsoever is sent, regardless of destination or protocol security level. This provides maximum privacy protection but breaks any functionality that depends on referrer data.

Use cases: Pages containing highly sensitive personal information, administrative interfaces, payment confirmation pages.

no-referrer-when-downgrade

Sends the full URL (origin, path, and query string) when the request destination has equal or greater security than the source. HTTPS to HTTP requests omit the Referer header entirely. This directive represents the historical default behavior for many websites and continues to be a practical choice when your primary concern is preventing HTTPS URLs from leaking through insecure connections. It protects against downgrade attacks while preserving useful referrer data for same-security navigation.

origin

Sends only the scheme, host, and port portion of the URL--the "origin"--regardless of destination. For a page at https://example.com/products?category=laptops, only https://example.com would be transmitted. This provides meaningful privacy protection while still indicating the source website.

origin-when-cross-origin

Sends the full URL for same-origin requests but only the origin for cross-origin requests. For internal navigation within your site, full referrer data is preserved for debugging and analytics. When linking to external sites or loading third-party resources, only the origin is revealed, protecting internal page paths while still indicating the source website.

same-origin

Restricts referrer transmission to same-origin requests only. Cross-origin requests receive no referrer information whatsoever. This policy is useful when you need full referrer data for internal operations but want to completely block external referrer leakage.

strict-origin

Sends only the origin and implements downgrade protection--HTTPS to HTTP requests send nothing. This provides stronger security guarantees by preventing any referrer leakage through insecure channels.

strict-origin-when-cross-origin

This directive combines the behaviors of strict-origin and origin-when-cross-origin. For same-origin requests, it sends the full URL. For cross-origin requests to equal-or-greater security destinations, it sends only the origin. For cross-origin requests to less secure destinations, it sends nothing. This is the OWASP-recommended configuration for production websites because it provides comprehensive protection while maintaining useful referrer data for same-origin operations.

unsafe-url

Sends the full URL (including query string) for all requests regardless of security level. The least private option, rarely recommended. The name reflects significant privacy and security risks.

no-referrer-when-downgrade: The Common Default

The no-referrer-when-downgrade directive represents the historical default behavior for many websites and continues to be a practical choice in many scenarios.

How It Works

Under no-referrer-when-downgrade, the browser sends complete referrer information when navigating to destinations that are equally or more secure than the source. The key security boundary is the HTTPS-to-HTTP transition:

• HTTPS to HTTPS: Full referrer sent
• HTTPS to HTTP: No referrer sent
• HTTP to HTTP: Full referrer sent
• HTTP to HTTPS: Full referrer sent

This behavior automatically protects HTTPS URLs from being leaked through insecure HTTP connections.

When to Use This Directive

The no-referrer-when-downgrade directive remains appropriate when your analytics or tracking systems require full referrer URLs for internal traffic analysis. It works well for websites with legacy integrations expecting referrer data on HTTPS-to-HTTPS requests, or those needing compatibility with older browser versions. If your primary concern is the security boundary between HTTPS and HTTP, and you're comfortable with full referrer sharing otherwise, this directive provides adequate privacy protection while preserving useful functionality.

Limitations

Despite its common use, no-referrer-when-downgrade has notable limitations. It sends full URLs including query parameters to same-security destinations, meaning third-party services, analytics providers, and advertising networks receive complete referrer data. Internal paths and page structures are exposed to external parties, and query parameters containing sensitive data could be logged by third-party servers. If these limitations concern you, strict-origin-when-cross-origin provides a more privacy-conscious alternative while maintaining many practical benefits.

For sites prioritizing internal analytics needs and comfortable with third-party referrer exposure, no-referrer-when-downgrade offers a reasonable balance. However, for modern privacy-conscious implementations, consider the stricter alternatives discussed below.

strict-origin-when-cross-origin: The Recommended Security Configuration

The strict-origin-when-cross-origin directive represents the OWASP-recommended configuration for production websites. It provides robust privacy protection while maintaining necessary functionality for most web applications.

Why OWASP Recommends This

This directive offers four key advantages that make it suitable for production deployment. First, it implements cross-origin referrer limitation by default--external requests receive only the origin, preventing exposure of internal URL structures and query parameters. Second, it maintains same-origin full referrer information for internal analytics, debugging, and logging needs. Third, it enforces downgrade protection, sending no referrer for HTTPS-to-HTTP requests to prevent secure URL leakage. Fourth, it's widely supported by modern browsers since approximately 2018, providing reliable behavior across user populations.

Implementation

The recommended OWASP configuration for your server:

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

Apache (.htaccess or server config):

Header set Referrer-Policy "strict-origin-when-cross-origin"

Nginx (server block):

add_header Referrer-Policy "strict-origin-when-cross-origin";

Express.js (application middleware):

app.use((req, res, next) => {
 res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');
 next();
});

PHP (script or auto_prepend_file):

header('Referrer-Policy: strict-origin-when-cross-origin');

For maximum compatibility with older browsers while still providing protection, you can specify multiple policies:

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

Browsers that understand strict-origin-when-cross-origin will use it, while older browsers will fall back to no-referrer.

Practical Behavior

Under strict-origin-when-cross-origin:

• Same-origin navigation: Full URL referrer sent
• Cross-origin navigation (same security): Only origin sent
• Cross-origin navigation (downgrade): No referrer sent
• Third-party resource loading: Only origin sent

This balance makes it appropriate for most production websites seeking to protect user privacy while maintaining essential functionality. Our web development team can help implement these security headers across your entire website infrastructure.

Implementation Methods

Implementing Referrer-Policy can be accomplished through multiple approaches, each with different scopes and use cases.

HTTP Response Header (Recommended)

The primary method for site-wide policy application. Add the header to all HTTP responses:

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

This approach is recommended for site-wide configuration because it's simple to implement and maintain, ensuring consistent behavior across all pages and resources without additional per-page configuration.

HTML Meta Element

For pages without server configuration access, such as static site hosting or third-party widgets:

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

Place this meta element early in your document <head> to ensure it takes effect before any resources are fetched. Note that the meta element cannot set policies requiring the "unsafe-url" value.

Element-Specific referrerpolicy Attribute

For fine-grained control over specific links and resources:

<a href="https://external-site.com" referrerpolicy="no-referrer">External Link</a>
<img src="https://analytics.example.com/pixel" referrerpolicy="origin" loading="lazy">
<script src="https://third-party.example.com/script.js" referrerpolicy="same-origin"></script>

The referrerpolicy attribute is supported on <a> and <area> elements for hyperlinks, <img> elements for images, <iframe> elements for embedded frames, <script> elements for scripts, <link> elements for stylesheet and resource links, and <form> elements for form submissions.

Precedence Rules

1. Element-specific referrerpolicy attributes take highest precedence
2. Meta element policies apply to the document and its resources
3. HTTP header policies apply to the response and its resources
4. Browser defaults apply when no policy is specified

Understanding this precedence helps diagnose unexpected behavior and design effective policy hierarchies. For most sites, consistent HTTP header configuration eliminates complexity and ensures predictable behavior. Automated security configurations through AI-powered development workflows can help maintain these headers consistently across large-scale deployments.

Best Practices for Production Deployment

Start with OWASP Recommendation

For most production websites, begin with the OWASP-recommended configuration:

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

This provides robust privacy protection while maintaining functionality for most use cases. Test thoroughly with this configuration before considering alternatives. The only reason to deviate is if specific functionality genuinely requires different behavior.

Audit Third-Party Dependencies

Before deployment, audit all third-party resources on your pages: analytics services, advertising networks, social media widgets, content delivery networks, font and icon services, and payment processors. Document each service's referrer requirements and test whether they function correctly with your chosen policy. Some services may expect referrer data for fraud prevention, attribution, or functionality. Create a matrix of third-party services and their referrer requirements, then determine whether element-specific policies can accommodate exceptions while maintaining strict defaults site-wide.

Handle Sensitive URL Parameters

Referrer policy is one layer of protection, not a complete solution. Implement additional safeguards: use POST requests for sensitive operations rather than URL parameters, implement session-based authentication tokens rather than URL-based alternatives, consider encrypting or hashing URL parameters that must be shared, and educate content creators about appropriate URL construction. Treat URLs as potentially public and avoid placing truly sensitive data in query strings.

Testing Checklist

Comprehensive testing should verify same-origin navigation preserves internal referrer tracking, cross-origin requests send only origin information, HTTPS to HTTP navigation sends no referrer, third-party resource loading follows expected policies, element-specific policies override document-level policies, and legacy browsers receive appropriate fallback behavior. Use browser developer tools to inspect outgoing requests and verify referrer header values match expectations. Test edge cases including mixed HTTPS/HTTP navigation, third-party resource failures, cached responses with different headers, and subdomain scenarios.

Monitor and Iterate

After deployment, monitor for broken analytics or attribution tracking, third-party service errors or warnings, user-reported issues with functionality, and security scanning tool results. Establish processes to address issues quickly and update policies as needed.

Common Pitfalls and How to Avoid Them

Relying on Browser Defaults

Browser defaults have changed over time and continue to evolve. What works today may not work tomorrow. Explicit configuration ensures consistent behavior regardless of user browser choice. Always set Referrer-Policy explicitly rather than relying on implicit browser behavior.

Inconsistent Policy Application

Applying different policies to different pages creates confusion and potential security gaps. Establish a site-wide policy and apply it consistently. Use element-specific attributes only for documented exceptions with clear justification.

Confusing Policy Names

The specification includes similar-sounding policy names that behave differently. The key differences are: origin sends only the origin regardless of destination, while origin-when-cross-origin sends full URL for same-origin and origin for cross-origin. Similarly, strict-origin sends only the origin with downgrade protection, while strict-origin-when-cross-origin adds full URL for same-origin requests. Finally, no-referrer eliminates all referrers, while no-referrer-when-downgrade allows referrers except on downgrade. Double-check policy names against official documentation before implementation.

Forgetting Query String Sensitivity

Even with strict policies, query parameters in URLs can be exposed through same-origin referrer sharing, browser history, server logs, and shared links. Treat URLs as potentially public and avoid placing truly sensitive data in query strings.

Testing Only Happy Path

Comprehensive testing must include edge cases and error conditions: mixed HTTPS/HTTP navigation, third-party resource failures, cached responses with different headers, subdomain and cross-origin scenarios, and browser extension interference. Test scenarios that might reveal unexpected referrer behavior.

Ignoring Legacy Browser Fallbacks

Older browsers may not support newer policies. Consider whether fallback behavior is acceptable. For most sites, browsers that don't support modern policies will use reasonable defaults. For critical privacy requirements, test with older browser versions to verify acceptable behavior.

Conclusion

The Referrer-Policy header provides essential control over how referrer information is shared across your website and with external parties. For most production websites, the OWASP-recommended strict-origin-when-cross-origin policy offers an excellent balance of privacy protection and functional preservation.

Key takeaways: implement an explicit policy rather than relying on browser defaults, start with the OWASP-recommended strict-origin-when-cross-origin configuration, audit third-party dependencies before deployment, test thoroughly across scenarios including edge cases, and combine referrer policy with other privacy practices like minimizing sensitive data in URLs. Remember that referrer policy is one component of a comprehensive privacy and security strategy.

Implementing referrer policy demonstrates commitment to user privacy while maintaining necessary functionality. With thoughtful implementation, Referrer-Policy becomes a valuable tool in your privacy and security toolkit. Start with the recommended configuration, audit your third-party dependencies, test thoroughly, and monitor for issues after deployment. Need help implementing security headers across your website? Our web development experts can audit your current configuration and implement best practices for optimal security and privacy.

Sources

1. MDN Web Docs: Referrer-Policy Header - Comprehensive technical reference covering all directives, syntax, and HTML integration methods
2. MDN Web Docs: Referrer Policy Configuration - Practical implementation guide with code examples and security best practices
3. OWASP HTTP Headers Security Cheat Sheet - Industry-standard security recommendations for production deployments