Referrer-Policy in Production: The Pragmatic Guide

What Referrer-Policy Should You Set in Production?

For most websites operating in a production environment, strict-origin-when-cross-origin is the recommended default. This policy offers a robust balance: it safeguards user privacy by limiting information shared with third parties, yet retains enough referrer data to keep your analytics and essential services functioning smoothly.

What Exactly Is Referrer-Policy? (And Why Does It Matter Beyond “Another Header”?)

The Referrer-Policy is an HTTP header (or sometimes a meta tag) that dictates how much referrer information—specifically, the URL of the previous page visited—your browser sends along with requests. This information is passed in the Referer header (yes, it's a historical misspelling that stuck).

Why should you care about this obscure-sounding header? Because it directly impacts three critical areas:

• User Privacy: Without a strict policy, your website could inadvertently leak sensitive internal URLs, user IDs, or query parameters to third-party sites when users click outgoing links. Nobody wants to be that website.
• Analytics & Marketing: Referrer data is the backbone of understanding where your users come from. Google Analytics, PostHog, and other tools rely on this to attribute traffic, track campaign performance, and show you user journeys.
• Security: While not a primary security control, a well-configured referrer policy can mitigate certain types of attacks, like those relying on leaked information or session fixation, by reducing the surface area for data exposure.

It’s not just for the security gurus; a thoughtful Referrer-Policy directly affects your ability to make informed marketing decisions and protect your users. Ignoring it is akin to leaving the back door slightly ajar.

Deconstructing the Referrer-Policy Options

There's a dizzying array of options, each with trade-offs. Let's break down the most relevant ones for a production environment:

no-referrer

Sends no referrer information whatsoever. Max privacy. Also breaks pretty much all cross-site analytics, many payment gateways, and affiliate tracking. Highly restrictive and generally not suitable for typical production sites unless you have extremely specific, isolated use cases where no external data is needed or shared.

no-referrer-when-downgrade

This was once a common default. It sends the full URL when navigating from an HTTPS page to another HTTPS page, or from HTTP to HTTP. However, if you navigate from an HTTPS page to an HTTP page, no referrer is sent. It protects against downgrading to an insecure connection but doesn't offer strong cross-origin privacy.

same-origin

Sends the full URL only for requests to the same origin (same scheme, host, and port). For any cross-origin request, no referrer is sent. Great for privacy, but significantly hampers cross-origin analytics and services.

origin

Sends only the origin (e.g., https://yourdomain.com) for all requests, regardless of whether they are same-origin or cross-origin, and regardless of protocol security. This prevents leaking paths and query strings but still reveals your domain.

strict-origin

Similar to origin, but with an important security enhancement: it sends the origin for same-origin requests and for cross-origin requests *only if* the destination is equally or more secure (HTTPS to HTTPS). No referrer is sent if downgrading from HTTPS to HTTP. A step up in privacy compared to origin.

origin-when-cross-origin

Sends the full URL for same-origin requests, but only the origin for cross-origin requests. It does not consider protocol security, meaning it would send the origin when going from HTTPS to HTTP. This can be problematic.

strict-origin-when-cross-origin (The Recommended Sweet Spot)

This policy sends the full URL for same-origin requests. For cross-origin requests, it sends only the origin, and only if the destination is equally or more secure (HTTPS to HTTPS). If navigating from HTTPS to HTTP, no referrer is sent. This is the gold standard for most modern web applications.

unsafe-url

Sends the full URL (including path and query parameters) for all requests, regardless of security protocol. This is a privacy and security nightmare. Never, ever use this in production. It lives up to its name.

The strict-origin-when-cross-origin Sweet Spot

Let's reiterate why strict-origin-when-cross-origin typically hits the mark for most production websites:

• Internal Clarity: When a user clicks a link within your own domain, your analytics (like Google Analytics or PostHog) see the full referring path. This is crucial for understanding user flow and engagement on your site.
• External Discretion: When a user navigates to an external site (e.g., a payment gateway like Stripe, an affiliate link, or a social media share), only your domain's origin is sent. This prevents sensitive paths or query parameters from your site (like /app/user/settings?id=123) from being exposed.
• Security-Conscious: It inherently protects against inadvertently sending referrer information to less secure (HTTP) destinations when coming from an HTTPS page, mitigating potential eavesdropping.

At SISL, when building web applications for our clients, we make this policy a standard recommendation. It ensures robust security without crippling essential operational insights. It’s a pragmatic choice that respects user privacy while allowing businesses to gather the data they need to grow.

Impact on Your Day-to-Day Operations and Third-Party Tools

Understanding how strict-origin-when-cross-origin interacts with common services is key:

• Analytics (Google Analytics, PostHog, etc.): You'll still get the referring origin for cross-site traffic, which is usually sufficient for campaign attribution and understanding traffic sources. You might lose specific *path* details from external referrers, but for your internal analytics, all paths are preserved. Most modern analytics platforms are designed to work well with this policy.
• Payment Gateways (Stripe, PayPal, etc.): These services often require *some* referrer information for fraud detection or to verify the source of a transaction. Sending just the origin (https://yourdomain.com) is typically sufficient and secure, allowing them to confirm the request came from your legitimate site. A no-referrer policy, conversely, would likely break these integrations.
• Error Monitoring (Sentry, Bugsnag): Referrer information can be valuable for debugging by providing context on where a user was coming from when an error occurred. The origin is usually enough to give developers a starting point.
• CDNs/Hosting (Vercel, Cloudflare, AWS Amplify): Your hosting provider or CDN doesn't directly consume the referrer policy in the same way an analytics tool does. However, your application, when served through these platforms, will adhere to the policy you set. These platforms often provide easy ways to configure HTTP headers, including Referrer-Policy. For instance, Vercel allows simple header configuration in your vercel.json.
• Marketing & Affiliates: If you rely heavily on affiliate marketing or detailed referrer tracking from external campaigns, you might notice a slight reduction in the granularity of incoming referrer URLs. However, the origin information is almost always present, allowing for accurate attribution at the domain level.

Implementing Your Referrer-Policy

You have a couple of primary ways to implement your Referrer-Policy:

1. HTTP Header (Recommended)

Setting the policy as an HTTP header is the most robust and widely supported method. It applies to all requests served by your web server or application gateway.

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

Examples:

• Nginx:

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

• Apache:

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

• Node.js (using Express and Helmet):

  const helmet = require('helmet');
  app.use(helmet.referrerPolicy({ policy: 'strict-origin-when-cross-origin' }));

• Vercel (in vercel.json):

  {
    "headers": [
      {
        "source": "/(.*)",
        "headers": [
          {
            "key": "Referrer-Policy",
            "value": "strict-origin-when-cross-origin"
          }
        ]
      }
    ]
  }

2. HTML <meta> Tag

You can also define the policy within your HTML <head> section:

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

This is useful as a fallback or if you don't have direct control over HTTP headers. However, an HTTP header will always override a meta tag, and the meta tag only applies to requests originating from that specific HTML document.

3. Link rel="noreferrer"

For specific outgoing links where you absolutely do not want to send any referrer information, you can add rel="noreferrer" directly to the <a> tag:

<a href="https://example.com" rel="noreferrer">External Link</a>

This is a per-link override and should be used sparingly for targeted privacy needs, not as a general site-wide policy.

Testing Your Referrer-Policy in the Wild

Once implemented, verify it's working as expected. Don't just set it and forget it.

• Browser Developer Tools: Open your browser's developer console (usually F12), go to the 'Network' tab, and observe the Referer header sent with requests. Pay close attention to cross-origin requests.
• Online Security Scanners: Tools like SecurityHeaders.com can quickly scan your site and report your current HTTP security headers, including Referrer-Policy.
• Simulate User Journeys: Click through your site, navigate to external services (Stripe checkout, social shares), and check your analytics dashboards for any unexpected drops in referrer data.

Final Thoughts: Don't Overthink, But Don't Ignore

The Referrer-Policy is one of those small, often overlooked details that can have a significant impact on your site's privacy posture and operational effectiveness. While it might not be the most exciting topic, getting it right is a testament to a well-engineered web presence.

Set strict-origin-when-cross-origin as your default, verify its implementation, and then you can mostly move on. If you find yourself wrestling with these security nuances, or need a hand setting up your web project with a pragmatic approach to both development and security, don't hesitate to get in touch. We at SISL are always ready to help untangle the complexities of modern web development.