No Referrer-Policy is set

Updated 2026-10-12

LowConfirmedQuick winweb.security-headers.referrer-policy-missing

66% of the 770 domains we could check get a warning for this. Sample: the first 1,000 domains by rank in the Majestic Million, checked on 2026-10-12. How we measured

What this check looks for

You have not said how much of your addresses to share when visitors follow a link away from your site.

Why it matters

Browsers default to a sensible policy now, so this is a small gap — but the default is a browser's choice, not yours, and a URL that contains a token or an account number is worth being deliberate about.

When the check passes, your report says: “A Referrer-Policy says how much of your URLs to share”.

What it costs your score

When this check fails it removes 3 points from your Web security score, before the status, confidence and repeat multipliers are applied. Web security carries a weight of 8 in the overall score.

It shares the web-security.headers family ceiling of 20 points: however many findings that family produces, together they cannot remove more than that from Web security. One underlying problem showing up in several places is still one problem.

Severity: low
Default confidence: confirmed
Status when triggered: warn
Deduction: 3 points
Family cap: web-security.headers · 20
Category: Web security
Module: Web security headers
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Set Referrer-Policy explicitly.

The default is reasonable but it is the browser's decision rather than yours.

Use strict-origin-when-cross-origin as the site-wide value. Current browsers already behave this way, so nothing changes for them; the header pins it for any client that would fall back to an older default.
Use no-referrer on pages whose URLs carry tokens, reset links or identifiers.
Set it where every response passes — the server or virtual host configuration, or your CDN — rather than in one application route, so error pages and static files carry it too. On IIS that is <customHeaders> in web.config.

How to confirm it worked

curl -sSI https://‹host›/ | grep -i referrer-policy

The configuration to publish

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

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

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

Apache

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

Caddy

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

Cloudflare

Rules → Overview → Create rule → Response Header Transform Rule → Set static → Referrer-Policy = strict-origin-when-cross-origin
(Dashboard path as at 2026-09; Cloudflare reorganised these pages and may again.)

The always flag matters: without it nginx omits the header on error responses, which are exactly the ones an attacker aims for. Note also that any add_header in a location block discards every add_header inherited from the server block.
Shown because the response identified Apache. Put it in the virtual host rather than .htaccess: .htaccess is re-read on every request, and Header always set there runs too late for responses the server generates itself.
A Transform Rule adds the header at Cloudflare's edge, so it applies only to responses that reach visitors through Cloudflare. An origin that is reachable directly — by IP, or through a DNS record that is not proxied — still serves the response measured here without it. Setting it at the origin covers both paths.

Technical detail

No Referrer-Policy header. Every current browser defaults to strict-origin-when-cross-origin, which sends only the origin across origins and nothing at all on a downgrade. Setting the header explicitly pins that behaviour rather than inheriting it, and lets you choose no-referrer for pages whose URLs carry sensitive parameters.

The policy governs the Referer header a browser sends when a visitor follows a link, loads an image or script, or submits a form, and the document.referrer value the next page's scripts can read. Under the older default, no-referrer-when-downgrade, which some clients still keep, the full address — path and query string included — goes to every HTTPS site the page links to or loads from, and to the analytics and advertising scripts running there; only a step down from HTTPS to plain HTTP sends nothing.

strict-origin-when-cross-origin keeps the full URL within your own origin, sends only the scheme and host to other sites, and sends nothing when an HTTPS page links to plain HTTP. no-referrer sends nothing anywhere, at the cost of the referral data partners and your own analytics see. same-origin and strict-origin also clear this check. Values that share more are reported by web.security-headers.referrer-policy-weak instead: unsafe-url and no-referrer-when-downgrade, which send the full URL across origins, and origin and origin-when-cross-origin, which send the origin even when an HTTPS page leads to plain HTTP.

A <meta name="referrer"> tag or a referrerpolicy attribute can set a policy for one page or one link, but this check reads the response header, which also covers responses the markup does not control.

Standards and references

MDN — Referrer-Policy

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the web security headers checker Build the fix