Referrerpolicy

Understanding the Referer Header

When users navigate between web pages or when browsers request external resources, the Referer header automatically transmits information about where the request originated. While this mechanism serves legitimate purposes for analytics, security, and user experience, it also creates potential privacy and security risks if left uncontrolled.

The Referrer-Policy header provides web developers with granular control over exactly what information gets shared, enabling more secure and privacy-conscious web applications. Understanding this mechanism is essential for building modern websites that respect user privacy while maintaining functionality.

According to MDN Web Docs, the Referer header has been a fundamental part of web architecture since the earliest days of the internet, though its name contains a famous historical typo.

How the Referer Header Works

• Navigation requests: When a user clicks a link from page A to page B, the browser sends a Referer header containing page A's URL
• Subresource requests: When a page loads images, scripts, or stylesheets, the browser sends the Referer header with requests to third-party domains
• Information range: Can be just the origin (https://example.com) or the complete URL including path and query string

As documented by web.dev best practices, modern browsers have converged on privacy-protective defaults that automatically limit referrer information sharing in many scenarios. This shift aligns with broader web security best practices that prioritize user data protection.

The Eight Policy Directives

The Referrer-Policy specification defines eight distinct directives that control referrer behavior in different ways. Each directive considers factors like whether the request is same-origin or cross-origin, and whether the request involves a security downgrade from HTTPS to HTTP.

Recommended: Strict-Origin-When-Cross-Origin

This policy sends the complete URL for same-origin requests while sending only the origin for cross-origin requests. It never sends referrer information when navigating from HTTPS to HTTP.

Use case: Balanced approach for most web applications, providing full referrer functionality internally while protecting user privacy externally.

Other Directives

The no-referrer policy completely suppresses the Referer header for all requests, providing maximum privacy protection. The unsafe-url policy sends complete URLs for all requests, representing the maximum information sharing with no protections. For most production applications, we recommend starting with strict-origin-when-cross-origin and adjusting based on specific requirements.

Review the complete directive documentation at MDN Web Docs for detailed implementation guidance. Our technical SEO services can help ensure your referrer configuration supports overall site performance.

Implementation Methods

Referrer-Policy can be configured through multiple mechanisms with different scope and priority characteristics. Understanding these implementation options helps you choose the appropriate approach for different scenarios.

1. HTTP Response Header

Set page-wide policy via server configuration:

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

Server configurations can set different policies for different routes, enabling fine-grained control based on content sensitivity or functional requirements. This approach works regardless of how the page is loaded and applies consistently across all browsers and clients. Implementing proper referrer policy is part of comprehensive server security configuration.

2. HTML Meta Element

Set policy within the document head:

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

The meta element should appear in the head section before any subresource requests are initiated. This method provides flexibility for static site generators and content management systems.

3. Element-Level referrerpolicy Attribute

Control individual elements for granular control:

<a href="https://external.example.com" referrerpolicy="origin">
 External Link
</a>
<img src="https://analytics.example.com/track" referrerpolicy="no-referrer">

Priority Order

1. Element-level referrerpolicy attribute (highest priority)
2. Page-level policy (meta tag or HTTP header)
3. Browser default (lowest priority)

This cascading priority enables protective defaults while maintaining flexibility for specific use cases. See MDN Web Docs implementation guidance for complete details. For comprehensive header security, explore our security audit services to ensure all security headers are properly configured.

JavaScript Integration

JavaScript provides programmatic access to referrer information and the ability to set referrer policies for dynamic requests. These capabilities are essential for modern single-page applications and interactive web experiences.

Reading the Referrer with JavaScript

// Get the referrer URL using document.referrer
const referrer = document.referrer;

// Check if referrer exists before using it
if (referrer) {
 console.log('User came from:', referrer);
}

// Parse referrer components using the URL API
const url = new URL(referrer);
console.log('Referrer origin:', url.origin);
console.log('Referrer path:', url.pathname);
console.log('Referrer query:', url.search);

The document.referrer property returns the URL of the page that linked to the current page, or an empty string if the user navigated directly. This read-only property is governed by the referrer policy of the referring page.

Setting Policy for Fetch Requests

// Make a fetch request with a specific referrer policy
const response = await fetch('/api/data', {
 referrerPolicy: 'strict-origin-when-cross-origin'
});

// Use withCredentials for same-origin requests that need credentials
const authenticatedRequest = await fetch('/api/private', {
 referrerPolicy: 'same-origin',
 credentials: 'include'
});

Dynamic Policy Changes

// Change policy on an existing link dynamically
const link = document.getElementById('dynamic-link');
link.referrerPolicy = 'no-referrer';

// Check current policy of an element
console.log('Current policy:', link.referrerPolicy);

These JavaScript capabilities integrate seamlessly with our web development services to create privacy-conscious applications. See web.dev JavaScript integration examples for comprehensive guidance.

Best Practices for Implementation

Recommended Policy: Strict-Origin-When-Cross-Origin

For most web applications, this policy provides an appropriate balance between functionality and privacy protection:

• Same-origin requests: Full URL sharing for internal analytics and debugging
• Cross-origin requests: Origin-only sharing to prevent exposure of specific page URLs
• Security downgrade: Automatic suppression when navigating to HTTP destinations

Progressive Enhancement for Special Cases

Use element-level overrides for specific needs while maintaining protective defaults:

<!-- Page default: protective policy -->
<meta name="referrer" content="strict-origin-when-cross-origin">

<!-- Analytics: no referrer for privacy -->
<img src="https://analytics.example.com/track" referrerpolicy="no-referrer">

<!-- Partner link: origin-level attribution -->
<a href="https://partner.example.com/recommend" referrerpolicy="origin">

Common Use Cases

• E-commerce: Protect product pages and search queries while enabling origin-level analytics.
• Content sites: Maintain internal referrer functionality while protecting article URLs from third-party exposure.
• Enterprise applications: Strict policies for sensitive business information and compliance requirements. Our compliance services can help implement comprehensive protection for regulated industries.

Regular security audits should include referrer policy configuration to ensure policies remain appropriate as applications evolve. Tools like security headers scanners can help identify pages that lack explicit configuration.

Following web.dev best practices recommendations ensures your implementation aligns with current browser standards and privacy expectations.

Browser Default Behavior

Modern browsers have converged on privacy-protective defaults, reflecting increased awareness of privacy concerns and the potential for referrer information misuse.

Impact of Browser Defaults

The adoption of strict defaults means cross-origin requests now send only the origin rather than complete URLs. Applications should:

• Audit dependencies on cross-origin referrer data
• Plan adaptations for analytics and attribution systems
• Not depend on receiving complete cross-origin URLs

Privacy-focused browser features like Firefox's Strict Tracking Protection and Safari's Intelligent Tracking Prevention provide additional protection, always trimming referrers for cross-site requests regardless of configured policy. These features complement comprehensive privacy practices that protect user data across all touchpoints.

Testing and Debugging

Using Browser Developer Tools

1. Open Network panel in DevTools
2. Examine request headers for Referer
3. Check response headers for Referrer-Policy
4. Test both same-origin and cross-origin requests

Common Debugging Issues

• Meta element not in head section before subresource requests
• Dynamic element insertion timing affecting policy application
• Proxy or CDN header modifications stripping policies

Verify that headers arrive at the browser as expected and that any intermediate infrastructure doesn't modify them. See MDN Web Docs browser compatibility for complete details. Our quality assurance services can help verify proper implementation across all browsers and devices.

Sources

1. MDN Web Docs: Referrer-Policy header - Official HTTP header reference with complete directive documentation
2. MDN Web Docs: Referrer policy configuration - Security implementation guide with practical examples
3. web.dev: Referer and Referrer-Policy best practices - Google's comprehensive best practices guide for privacy-conscious development