The Ultimate Guide to the Referrer-Policy HTTP Header

When users navigate from your website to another destination on the internet, their browser automatically shares information about where they came from. While this mechanism is fundamental to web analytics and traffic tracking, it introduces a severe security and privacy risk known as "URL parameter leakage." The Referrer-Policy HTTP header is your primary defense against accidentally broadcasting sensitive information to third-party domains.

In this comprehensive guide, we'll dive deep into what the Referrer-Policy is, how the Referer header works, the security implications of ignoring it, and how web developers, security engineers, and system administrators can implement the optimal configuration to protect user privacy without breaking critical site functionality.

Quick Answer: What is Referrer-Policy?

Referrer-Policy is an HTTP response header that dictates exactly how much referrer information (the URL the user is currently on) the browser should include when navigating to a different page or fetching subresources (like images or scripts).

The Best Practice Configuration: For modern web applications, the gold standard and recommended baseline is strict-origin-when-cross-origin.

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

This directive ensures:

Same-origin requests receive the full URL (useful for your own internal analytics).
Cross-origin HTTPS requests receive only the domain name (origin), protecting sensitive URL paths and parameters.
HTTP (insecure) requests receive absolutely nothing, preventing data leakage over unencrypted channels.

🔍 People Also Ask (PAA)

What is the default Referrer-Policy? Since late 2020 (Chrome 85+, Firefox 87+, Edge 85+), the default policy enforced by modern browsers if you do not specify a header is strict-origin-when-cross-origin. However, explicitly setting the header is a security best practice to ensure consistent behavior across all clients, including older browsers and specific programmatic API clients.

Can I set Referrer-Policy in HTML? Yes. If you do not have access to server configurations to set HTTP response headers, you can use a meta tag in the <head> of your HTML document: <meta name="referrer" content="strict-origin-when-cross-origin">. Note that the HTTP header is much preferred, as the meta tag may not reliably apply to all early-loading subresources.

Why is 'Referer' misspelled? The HTTP Referer header is famously misspelled (missing the second 'r'). This typo was introduced in the original HTTP specification in the 1990s and became permanently codified into the standard to maintain backwards compatibility. The security header, Referrer-Policy, is spelled correctly.

The Anatomy of the HTTP Referer

To understand the policy, we first have to understand the mechanism it governs. When a browser issues a request-whether it's clicking a link, submitting a form, or loading an image-it often includes the Referer header to let the destination server know the origin of the request.

Consider a user navigating from their dashboard to an external support site.

> GET /help-article HTTP/2
> Host: external-support-site.com
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
> Accept: text/html,application/xhtml+xml
> Referer: https://your-site.com/dashboard/user?session_token=xyz987&email=user@example.com

Notice the last line. The Referer header contains the absolute, fully-qualified URL of the page the user just left. This includes the path (/dashboard/user) and the query string (?session_token=xyz987&email=user@example.com).

The Privacy and Security Risks: URL Parameters Leak

Why is this dangerous? Developers frequently pass state and sensitive data through URL parameters. While HTTPS encrypts the URL in transit (protecting it from network sniffers), the URL is fully decrypted at the destination server.

If your application places sensitive data in the URL, the Referer header effectively hands that data to third-party sites.

Common data leaked via the Referer header includes:

Authentication/Session Tokens: Allowing a third-party to hijack the user's session.
Password Reset Links: Tokens meant to be one-time-use can be intercepted if a user clicks an external link on the reset page.
Personal Identifiable Information (PII): Names, email addresses, and phone numbers.
Protected IDs: Internal database IDs or medical record numbers.

🚨 CRITICAL VULNERABILITY: Token Leakage via Referer
If a user is authenticated via a URL token (e.g., Magic Links) and clicks a social media icon on your page, the social media network receives the full URL, including the active authentication token, in their server logs. A malicious actor with access to those logs could impersonate the user.

Referrer-Policy Directives Breakdown

The Referrer-Policy header accepts several directives, ranging from completely permissive to fully restrictive. Understanding what each does is crucial for System Administrators balancing security with functionality.

1. `no-referrer`

Sends absolutely no Referer header under any circumstances. Not for internal links, not for external links.

Privacy: Maximum.
Use Case: Highly sensitive applications (banking, healthcare) where internal analytics are handled via different mechanisms, and privacy is the absolute highest priority.
Downside: Breaks internal analytics that rely on referrers to track user flow.

2. `no-referrer-when-downgrade`

Sends the full URL when going from HTTPS to HTTPS, or HTTP to HTTP. It sends nothing when downgrading from secure HTTPS to insecure HTTP.

History: This was the historical default behavior of browsers before Referrer-Policy existed.
Flaw: It still leaks full URLs (including query parameters) to any external site, as long as that site has an SSL/TLS certificate.
Verdict: Do not use. It provides a false sense of security in the modern web where almost every site uses HTTPS.

3. `origin`

Strips the path and query string, sending only the scheme, host, and port.

Example Output: Referer: https://your-site.com/
Use Case: You want external sites to know traffic is coming from your domain (to maintain SEO relationships or affiliate tracking) but refuse to reveal the exact page or any parameters.
Downside: It also strips the path for same-origin (internal) requests, making internal traffic analysis difficult.

4. `origin-when-cross-origin`

Sends the full URL for same-origin requests (e.g., your-site.com/pageA to your-site.com/pageB), but strips it down to just the origin for external requests (e.g., your-site.com to external.com).

Privacy: Good.
Downside: It will send the origin even when downgrading from HTTPS to HTTP.

5. `same-origin`

Sends the full URL for internal (same-origin) requests, but sends absolutely nothing for external requests.

Privacy: Very High.
Use Case: Strict environments where you want robust internal analytics but refuse to give any traffic data to external domains.

6. `strict-origin`

Sends the origin to HTTPS destinations, but sends nothing to HTTP destinations.

Verdict: A safer version of origin because it prevents data leakage over unencrypted channels.

7. `strict-origin-when-cross-origin` ✓ (The Recommended Standard)

Sends the full URL for internal (same-origin) requests. Sends only the origin for external (cross-origin) HTTPS requests. Sends nothing when downgrading to HTTP.

[🔒 https://your-site.com/secure-dashboard?id=999]

User clicks link to -> https://analytics-partner.com/

Resulting Request Header:
Referer: https://your-site.com/
(Path and ID are safely stripped!)

Privacy: Excellent balance.
Functionality: Preserves full internal tracking for your marketing teams while protecting users from third-party leakage.
Verdict: The standard for 99% of web applications today.

8. `unsafe-url`

Always sends the full URL, everywhere, regardless of cross-origin or security downgrades.

⚠️ SECURITY WARNING: unsafe-url
Using this directive explicitly forces the browser to leak your full URL paths and query strings to any domain, including unencrypted HTTP endpoints. SecHead scanners will flag this as a critical failure.

Technical Implementation

Implementing the Referrer-Policy header is straightforward across all major web servers and modern application frameworks. Security Engineers should ensure this is enforced at the edge/proxy level whenever possible.

Nginx Configuration

Open your Nginx configuration file (usually /etc/nginx/nginx.conf or within a specific server block) and add the following line. The always flag ensures it is served even on error pages.

# /etc/nginx/conf.d/security.conf
server {
    listen 443 ssl http2;
    server_name example.com;

    # Apply Referrer-Policy
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    
    # Other headers...
}

Apache Configuration

For Apache, ensure the mod_headers module is enabled (a2enmod headers). Then, update your .htaccess or virtual host configuration file:

<IfModule mod_headers.c>
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Node.js (Express) Configuration

If you are using Node.js with the Express framework, the helmet middleware is the industry standard for managing security headers. Helmet sets strict-origin-when-cross-origin by default, but you can configure it explicitly.

const express = require('express');
const helmet = require('helmet');
const app = express();

// Use Helmet with explicit Referrer-Policy
app.use(helmet({
  referrerPolicy: {
    policy: "strict-origin-when-cross-origin",
  },
}));

app.get('/', (req, res) => {
  res.send('Secure headers applied!');
});

Next.js Configuration

In Next.js, HTTP headers are configured in the next.config.js file.

// next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Referrer-Policy',
            value: 'strict-origin-when-cross-origin',
          },
        ],
      },
    ];
  },
};

Cloudflare & CDNs

If you use a CDN like Cloudflare, you can enforce this header globally using Cloudflare Rules (Transform Rules -> HTTP Response Header Modification) or via Cloudflare Workers, ensuring consistent security regardless of your origin server's configuration.

Troubleshooting & Common Pitfalls

While strict-origin-when-cross-origin is highly recommended, implementing Referrer-Policy without understanding your architecture can lead to unexpected breakages.

Issue 1: Third-Party Authentication Flow Failures

Symptom: Single Sign-On (SSO) or OAuth flows (like "Log in with Google" or SAML) suddenly fail. Cause: Some legacy authentication gateways rely on the Referer header to validate that the auth request originated from an approved application path, rather than validating via proper state tokens or CORS. Solution: Modernize the OAuth implementation. Rely on redirect_uri validation and CSRF state tokens rather than the Referer header. If immediate modernization isn't possible, you may need a page-specific policy.

Issue 2: Broken External Affiliate Tracking

Symptom: Your marketing team reports that affiliate networks are no longer crediting your site for outgoing sales traffic. Cause: If you set same-origin or no-referrer, external sites receive no information. Even with strict-origin-when-cross-origin, if the affiliate relies on a specific URL path (e.g., your-site.com/affiliate-hub/product-x) to attribute traffic, the stripped origin (your-site.com/) won't be enough. Solution: Affiliate links should rely on UTM parameters or specific affiliate query strings attached to the destination URL (e.g., external.com/product?ref=yoursite), not on parsing the Referer header of the incoming request.

Issue 3: Missing Internal Analytics

Symptom: Your self-hosted Matomo or Google Analytics shows a massive spike in "Direct" traffic and a drop in internal navigational flow. Cause: You likely deployed origin or no-referrer across your entire site. Solution: Switch to strict-origin-when-cross-origin to restore full internal path tracking.

Best Practices for Web Developers & Security Engineers

The Referrer-Policy header is an excellent defense-in-depth mechanism, but it should not be your only defense against data leakage.

Stop putting sensitive data in URLs: This is the root cause of the problem. Access tokens, passwords, and PII should be transmitted via HTTP POST bodies, standard Authorization headers (Bearer tokens), or secure HttpOnly cookies.
Use short-lived, single-use tokens: If you absolutely must use URL parameters for actions like password resets, ensure the token is invalidated the millisecond it is used.
Audit your outbound links: Periodically review the external resources your application links to. Ensure target="_blank" links utilize rel="noopener noreferrer" for an added layer of DOM-level protection against window.opener exploitation, which pairs well with Referrer-Policy.
Combine with Content Security Policy (CSP): The Referrer-Policy complements CSP well. While CSP dictates what your site can load, Referrer-Policy dictates what your site reveals when users leave.

Frequently Asked Questions (FAQ)

1. Does Referrer-Policy affect SEO?

No, the Referrer-Policy header does not negatively impact your site's search engine ranking. In fact, providing a secure browsing experience aligns with Google's broader E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) guidelines. However, if you strip referrers, other sites won't see your specific URLs in their analytics, which might obscure your backlink profile to them.

2. Can I set different policies for different pages?

Yes! Since it's an HTTP response header, your server can conditionally serve different policies based on the route. For example, your public blog could use strict-origin-when-cross-origin, while your highly sensitive /billing portal could return no-referrer.

3. What happens if I declare both the HTTP header and the HTML meta tag?

If both are present, the browser will generally prioritize the most restrictive policy, or the one defined at the document level (the meta tag) for document navigations. However, mixing them can cause unpredictable behavior across different browser engines. Best practice is to rely exclusively on the HTTP response header.

4. Does Referrer-Policy protect against Cross-Site Request Forgery (CSRF)?

Only marginally, and it should never be used as a primary CSRF defense. While some old frameworks checked the Referer header to ensure requests came from the same site, this is easily spoofed or stripped. Use anti-CSRF tokens (Synchronizer Token Pattern) or SameSite cookies instead.

5. Why do browsers have a default policy now?

Historically, browsers sent the full URL everywhere. As the web grew and data privacy laws (like GDPR and CCPA) became stricter, browser vendors (Google, Mozilla, Apple) realized that leaking user activity by default was unacceptable. The shift to strict-origin-when-cross-origin was a massive win for global privacy.

6. Are there specific policies for subresources like images?

The HTTP response header applied to the HTML document dictates the default policy for all subresources loaded by that document. However, you can override this on a per-element basis in HTML using the referrerpolicy attribute: <img src="tracker.gif" referrerpolicy="no-referrer">.

7. Will Referrer-Policy hide my IP address?

No. The Referrer-Policy only controls the HTTP Referer header. It has absolutely nothing to do with network-level IP addresses, TCP/IP packets, or hiding client locations.

8. Is 'unsafe-url' ever acceptable?

In modern security paradigms, no. There is virtually no legitimate architectural reason to broadcast full URL paths to external domains over insecure HTTP connections.

9. How does this interact with the `rel="noreferrer"` HTML attribute?

The rel="noreferrer" attribute on an <a> tag overrides the site-wide Referrer-Policy for that specific link click, acting as if the policy was no-referrer for that single navigation.

10. Can third-party scripts read my URL even if I use strict Referrer-Policy?

Yes. Referrer-Policy only prevents the browser from sending the URL in the HTTP header during navigation or subresource fetching. If you embed a third-party JavaScript file on your page (like Google Analytics or a malicious script), that script can simply execute window.location.href to read the full URL and beacon it back to their servers. This is why you also need a strong Content Security Policy (CSP).

11. Does iOS Safari support this header?

Yes. Apple's WebKit engine (Safari on iOS and macOS) fully supports the standard Referrer-Policy directives. Safari actually has additional built-in Intelligent Tracking Prevention (ITP) features that independently restrict cross-site tracking.

12. How can I test if my Referrer-Policy is working?

You can use your browser's Developer Tools (Network Tab). Click on a request, scroll down to the "Request Headers" section, and inspect the value of the Referer header. Alternatively, utilize specialized security scanning tools like SecHead.

13. What is the difference between Referrer-Policy and CORS?

They operate in opposite directions. CORS (Cross-Origin Resource Sharing) controls whether other sites are allowed to read data from your site. Referrer-Policy controls what data your site gives to other sites when navigating away.

14. Should an API server set Referrer-Policy?

If the API returns JSON and is not navigated to directly by a browser, the header is technically inert. However, security scanners will often flag its absence. It is best practice to include standard security headers on all responses, even API endpoints, to establish a secure baseline.

15. Does strict-origin-when-cross-origin strip query parameters on HTTPS to HTTPS cross-origin?

Yes. The term "origin" refers strictly to the protocol, domain, and port. So https://yoursite.com/page?id=1 becomes just https://yoursite.com/. All path and query data is removed.

Conclusion

Securing your web application is an ongoing process of layering defenses. By taking five minutes to configure the Referrer-Policy header, you close a massive loophole that historically leaked sensitive user data, authentication tokens, and internal navigation patterns to the rest of the web.

Ensure your servers are explicitly enforcing strict-origin-when-cross-origin today, and remember to continually audit your URLs to keep sensitive information out of paths and query parameters.

After configuring your servers, run a comprehensive check to ensure your entire stack is secure.

Continue your journey into web security with these related, deep-dive articles from the SecHead team:

SEO Metadata

Meta Title: Referrer-Policy Explained: Choosing the Right Security Value
Meta Description: Learn how the Referrer-Policy HTTP header prevents URL parameter leakage. Discover the best configuration for your server to secure web applications and protect user privacy.
URL Slug: /blog/referrer-policy-explained
Target Keywords: Referrer-Policy, strict-origin-when-cross-origin, HTTP Referer, URL parameters leak, web security, header security.