Skip to main content

Security Headers

Referrer-Policy: Controlling What You Leak in Links

Decide how much URL information travels to other sites.

Quick answer

Referrer-Policy controls how much of the current URL is sent in the Referer header when users click links or load resources. A policy like strict-origin-when-cross-origin protects privacy without breaking analytics.

When a visitor navigates from your site to another, the browser can send your page's full URL as the referrer. Referrer-Policy limits this to protect sensitive paths and query strings from leaking to third parties.

Check your website

See how your site handles referrer-policy: controlling what you leak in links — free, no account needed.

For business owners

URLs often contain sensitive data — reset tokens, internal IDs, search terms, account references. Without a referrer policy, that information can leak to external sites and analytics providers. Setting a sensible policy protects customer privacy and reduces compliance risk, while still allowing your own analytics to work.

How it works (technical)

The header sets the browser's referrer behaviour, e.g. Referrer-Policy: strict-origin-when-cross-origin. Common values:

  • no-referrer — send nothing.
  • same-origin — send full URL only to your own site.
  • strict-origin-when-cross-origin — send the full URL to same-origin, only the origin cross-origin, and nothing when downgrading HTTPS→HTTP. This is the modern browser default and a good choice.

Real-world example

A support portal put ticket IDs in the URL. Clicking an external help link sent the full URL — including the private ticket reference — to the third-party site as a referrer. Setting Referrer-Policy: strict-origin-when-cross-origin limited cross-site referrers to just the origin, stopping the leak.

Why it matters

Referrer leakage is a quiet privacy and security issue that scanners and privacy audits flag. A single header closes it while preserving legitimate analytics.

How to fix it

  1. Set Referrer-Policy: strict-origin-when-cross-origin globally as a safe default.

  2. Use a stricter value like no-referrer for highly sensitive applications.

  3. Avoid putting secrets (tokens, IDs) in URLs in the first place.

  4. Re-scan and verify the header is applied site-wide.

Best practices

  • Default to strict-origin-when-cross-origin unless you need stricter privacy.

  • Keep sensitive data out of URLs regardless of referrer policy.

Common mistakes

  • Using the permissive unsafe-url, which leaks full URLs everywhere.

  • Relying on referrer policy instead of keeping secrets out of URLs.

Frequently asked questions

Will this break my analytics?

strict-origin-when-cross-origin still sends the origin cross-site and full URLs same-site, so first-party analytics keep working.

Put this into practice

See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.

Scan your website free

See Pro plans · Create account