Referrer Policy Explained

Every time a user clicks a link or your page loads a third-party resource, the browser silently sends a Referer header to the destination. This header contains the URL of the page the user was viewing, including the full path and any query parameters.

This seemingly innocent behavior creates a massive privacy risk. URLs frequently contain sensitive information like password reset tokens, email addresses, search queries, and session identifiers. Without a proper Referrer-Policy, this data is silently transmitted to every third-party service your page loads, from Google Fonts to analytics scripts to ad networks.

This guide explains how the Referrer-Policy header works, why it is critical for privacy and GDPR compliance, and exactly how to configure it correctly on any web server.

The Silent Data Carrier

When a user navigates from your site to another, or when your page loads a third-party resource (script, font, image, stylesheet), the browser sends a Referer header containing the URL of the originating page.

This means every third-party script, image, and font request reveals exactly which page the user was viewing, including the full URL path and query string. If your URL contains /reset?token=abc123, that token is sent to every external resource loaded on the page.

Visualizing the Leak

The Referrer-Policy HTTP header controls how much of this URL data the browser includes. By setting the right policy, you can strip sensitive query parameters while still allowing basic navigation to work correctly. You can review the exact specification in the W3C Referrer Policy document.

Common URL Leak Vectors

URLs frequently contain sensitive information that should never leave your domain:

Legal and Compliance Implications

The risk compounds with third-party requests. The average marketing website makes 30–80 external requests per page load. Each one receives the full Referer header unless you configure a policy to restrict it.

Referrer data leaks have caused significant real-world incidents:

• Healthcare portals: Patient dashboard URLs containing diagnosis codes were leaked to analytics providers via the Referer header, resulting in HIPAA violations and GDPR complaints.
• Password reset exploits: Reset tokens in URLs were captured by third-party CDN providers. Attackers with access to CDN logs could hijack accounts.
• German court ruling (2022): A German court found that loading Google Fonts from Google's servers (which transmits the user's IP and Referer to Google) violated GDPR, awarding €100 in damages per affected user.
• Financial services: Investment portfolio pages with account IDs in URLs were leaked to social media tracking pixels.

1. Run an automated scan: Use the Referrer Policy Checker to instantly see your current setting and whether it is adequate.
2. Check response headers manually: Open browser DevTools → Network tab → click any request → look for the Referrer-Policy response header.
3. Inspect outbound requests: In DevTools, filter by third-party domains and check their request headers for the Referer field. If it contains a full URL path with query parameters, your policy is too permissive.
4. Audit URLs for PII: Use the PII Leak Checker to scan your pages for exposed personal data in URLs.

The Golden Standard

This provides the best balance:

• Same-origin: Full URL sent (internal navigation works normally)
• Cross-origin HTTPS→HTTPS: Only the domain is sent (strips sensitive paths)
• HTTPS→HTTP downgrade: Nothing is sent (prevents interception)

Server Configuration

Add it to your web server or CDN configuration. Here are examples for common setups:

1. Always set Referrer-Policy explicitly, do not rely on browser defaults, as they can vary across versions and may change.
2. Use POST for sensitive forms, GET requests put data in the URL, which the Referer header then leaks. POST requests keep data in the request body.
3. Avoid putting PII in URLs, replace email-based URLs with opaque UUIDs. See the PII Data Exposure guide for details.
4. Self-host fonts and libraries, this eliminates referrer leaks to third-party domains entirely.
5. Combine with a strong CSP, a Content Security Policy restricts which domains can be contacted in the first place.
6. Set the policy at the server level, not per-link, the rel="noreferrer" attribute only works for individual links and is easy to forget.

• Setting unsafe-url: This sends the full URL (including path and query parameters) to every external request. Never use this value.
• Relying on rel="noreferrer" alone: This only works for links you manually tag. It does nothing for third-party scripts, fonts, or images that load automatically.
• Forgetting about meta-tag conflicts: If both an HTTP header and a <meta name="referrer"> tag are present, the most restrictive one wins. This can cause unexpected behavior.
• Not auditing after changes: Hosting migrations and CDN updates can reset or override your Referrer-Policy. Always verify with a Referrer Policy Checker.
• Ignoring API endpoints: REST API responses also send Referer headers. If your API URLs contain tokens or user IDs, they are equally vulnerable.

The Referrer-Policy header is a simple, one-line change that prevents an entire category of data leaks. Without it, every third-party resource your page loads receives the full URL the user was viewing, including any tokens, email addresses, or sensitive query parameters.

Set strict-origin-when-cross-origin as your default and combine it with URL hygiene practices to eliminate this risk entirely.