The Referrer-Policy leaks full URLs

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

What this check looks for

The policy you set sends your complete addresses — including the path and anything after the question mark — to other websites visitors click through to.

Why it matters

Password reset links, invitation links, search queries and account identifiers all live in URLs. This policy hands them to every site a visitor clicks through to, and to every analytics script on those sites.

When the check passes, your report says: “The Referrer-Policy keeps paths and query strings private”.

What it costs your score

When this check fails it removes 5 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: 5 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

Change the policy to strict-origin-when-cross-origin or stricter.

Anything in your URLs is being handed to every site your visitors click through to.

Replace the value with strict-origin-when-cross-origin.
Check what is in your URLs — if tokens or identifiers appear there, use no-referrer on those pages and consider moving them out of the URL.

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

‹detail›

unsafe-url sends the full URL to every destination, including over plain HTTP. no-referrer-when-downgrade was the old browser default and still sends the full URL to any HTTPS destination. origin-when-cross-origin sends the full URL to same-origin destinations and the origin elsewhere, which is better but still more than strict-origin-when-cross-origin.

Note that a browser uses the *last* token it recognises in a multi-value header, so the fallback form is graded on its final value, not its first.