The Referrer-Policy is not one of the strict policies

Updated 2026-10-12

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

25% of the 259 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

The policy you set shares more of your addresses with other websites than the strict policies do, or is not a value browsers recognise.

Why it matters

Password reset links, invitation links, search queries and account identifiers all live in URLs. The weakest policies hand them to every site a visitor clicks through to; the milder ones still announce your site over any unencrypted connection a visitor follows out of it.

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.

The strict policies give away nothing more than the browser default, and nothing at all over plain HTTP.

Replace the value with strict-origin-when-cross-origin. If you set origin to share only your site's name, strict-origin does the same without the plain-HTTP exception.
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. origin sends only the origin — scheme and host — everywhere, including on your own pages.

origin and origin-when-cross-origin are valid policies, and neither ever sends a path or query string to another site. They are graded here because both still send the origin when an HTTPS page links to or loads from plain HTTP, where anyone on the network path can read it; strict-origin and strict-origin-when-cross-origin send nothing in that case, at no cost to anything else.

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. Several Referrer-Policy headers are combined into one such list, so the last header with a recognised policy is the one in force, and that is the one graded here.

Standards and references

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