Referrer-Policy

The Referer header (mis-spelled in the original spec) tells the destination server which page the user came from. By default, that includes the full URL: path, query string, fragment. URLs leak more sensitive information than people realize: password reset tokens, OAuth state parameters, search queries with personal info, internal session identifiers. Referrer-Policy is the response header that lets you reduce or eliminate this leakage.

Modern browsers default to strict-origin-when-cross-origin since 2020-2021, which is one of the values this check accepts. If you have not explicitly set the header, your site may already pass on browsers that respect modern defaults, but older browsers and some embedded WebViews fall back to the leakier no-referrer-when-downgrade default. Setting the header explicitly removes the ambiguity.

How the check works

Per primary host, the check looks at the Referrer-Policy response header. The value is normalized to lowercase and matched against an allow-list of strict policies:

• no-referrer: never send the Referer header at all. Most restrictive.
• strict-origin-when-cross-origin: send full URL on same-origin requests, only the origin (scheme + host) on cross-origin HTTPS, nothing when downgrading to HTTP. The modern browser default; recommended for most sites.
• same-origin: send full Referer on same-origin requests, no Referer at all on cross-origin requests.

Anything else, including missing header, scores zero. Notably, weaker values like origin, origin-when-cross-origin, no-referrer-when-downgrade, strict-origin, and unsafe-url all fail this check.

How the verdict maps to evidence

• Pass (6/6 per host): Referrer-Policy is exactly no-referrer, strict-origin-when-cross-origin, or same-origin.
• Fail (0/6 per host): header missing, or set to any other value.

Fix: pick a value, set the header

Three accepted values, in order of restrictiveness. Pick based on what your site needs:

• strict-origin-when-cross-origin (recommended). Matches modern browser defaults; explicit header removes ambiguity. Good for marketing sites, content sites, and most apps.
• same-origin. Use when your site has no need for cross-origin Referer at all (no third-party analytics that depend on Referer, no inbound-link attribution from your own domain to others). Effectively no-referrer for everything outside your origin.
• no-referrer. Most restrictive. Use for high-sensitivity apps (banking, healthcare, anything with tokens routinely in URLs) where you never want to leak any referrer information.

Per-server snippets

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

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

header Referrer-Policy "strict-origin-when-cross-origin"

Set response header via Transform Rules:
  Header name:  Referrer-Policy
  Header value: strict-origin-when-cross-origin

In a Response Headers Policy, add:
  Header: Referrer-Policy
  Value:  strict-origin-when-cross-origin

import helmet from "helmet";
app.use(helmet.referrerPolicy({ policy: "strict-origin-when-cross-origin" }));

# settings.py
SECURE_REFERRER_POLICY = "strict-origin-when-cross-origin"

# config/initializers/referrer_policy.rb
Rails.application.config.action_dispatch.default_headers["Referrer-Policy"] = "strict-origin-when-cross-origin"

Per-page overrides via meta tag

If you cannot set the header at the response layer (rare; usually you can), HTML supports a meta tag for per-page overrides:

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

RedScore evaluates the response header, not the meta tag, so this does not satisfy the check. Use the response header for scoring; reserve the meta tag for tightening on specific pages where you want stricter policy than the site-wide default.

Verify the fix

• curl -sI https://yourdomain.tld | grep -i referrer-policy should show one of the accepted values.
• Repeat for each primary HTTPS host.
• Open the page in a browser, click a cross-origin link, then check the destination's request headers (DevTools Network tab). The Referer should be empty or origin-only, depending on your policy.
• Re-run the RedScore lookup. Pass requires the header on every primary HTTPS host.

Common pitfalls

• Setting a weaker policy and assuming it passes. origin, origin-when-cross-origin, no-referrer-when-downgrade, strict-origin, and unsafe-url all score zero. Stick to one of the three accepted values.
• Multiple Referrer-Policy headers from different layers. CDN sets one value, origin sets another. Browsers honor whichever the spec disambiguates to (typically the later or stricter), but the check sees what your edge actually serves. Set at one layer and confirm.
• Tokens in URLs. Even with a strict Referrer-Policy, putting password reset tokens, API keys, or session IDs in URL paths or query strings is a leak waiting to happen. Use POST bodies, fragment identifiers (#), or short-lived token exchanges instead.
• Analytics that depend on Referer. Some marketing analytics (referral tracking, conversion attribution) read the Referer header. strict-origin-when-cross-origin still gives them the origin, which is usually enough; same-origin and no-referrer break their attribution. If you use those tools, audit before tightening.
• Old browsers without modern defaults. IE11 and older mobile WebViews use the leaky no-referrer-when-downgrade default. Setting the header explicitly is the only way to protect users on those clients.
• Per-link rel=noreferrer. The HTML rel="noreferrer" attribute on individual links is independent of the response header and only affects that link. Useful for outbound links you want to fully scrub; not a substitute for the site-wide policy.