EngineeringScore
Security Small

Add a Referrer-Policy header

By default, browsers send the full URL of the page a visitor is leaving, including query strings, as the Referer header on every outbound link click and resource request. A Referrer-Policy header controls how much of that URL is shared with the destination, which matters whenever URLs can contain session tokens, password-reset codes, or internal identifiers.

Why it matters

Without a Referrer-Policy, full page URLs (which may contain session tokens, search terms, or internal paths) are leaked to every third-party site a user navigates to or loads a resource from.

How to fix

  1. 1 Add Referrer-Policy: strict-origin-when-cross-origin (or stricter) to responses.
  2. 2 Review any analytics or link-tracking that depends on referrer data before tightening further.

Common mistakes

  • Setting no-referrer, which is maximally private but also breaks legitimate use cases like affiliate tracking or analytics that the business depends on.
  • Forgetting that the policy also applies to same-site navigation, not just links to external sites, so overly strict settings can break internal analytics.
  • Assuming the header alone protects sensitive data in URLs: the real fix is to stop putting tokens in URLs at all and use the header as defense in depth.

How to verify

  1. 1 Inspect the response headers for a Referrer-Policy value such as strict-origin-when-cross-origin.
  2. 2 Click an outbound link to a third-party site and inspect the Referer header the browser actually sent (via devtools network tab) to confirm it matches the policy.
  3. 3 Confirm any analytics or attribution tooling that depends on referrer data still receives what it needs.

Related checks

Security CSPSecurity Permissions Policy

Ready to see where you stand?

Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.

Scan your site