The fix, in one snippet
Referrer-Policy: strict-origin-when-cross-originIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now reads the Referrer-Policy header on the response to / and, failing that, a <meta name="referrer"> element. The values no-referrer, same-origin, strict-origin and strict-origin-when-cross-origin pass. origin and origin-when-cross-origin pass with a note, because they still send the origin over an HTTPS-to-HTTP downgrade. unsafe-url and no-referrer-when-downgrade fail, since both send the full URL cross-origin. A missing policy is reported as low: browsers have defaulted to strict-origin-when-cross-origin since Chrome 85 and Firefox 87, so the exposure is limited to older clients, but an explicit header removes the dependence on browser defaults. When several comma-separated values are present, the last one the browser recognises wins, which is the intended fallback mechanism.
Why it matters
The Referer header carries the URL of the page a request came from. Under a permissive policy, that is the full URL including path and query. Consider a password-reset page at https://example.com/reset?token=8f3a... that loads an analytics script and a web-font from third parties: each of those vendors receives the reset token in the Referer of the font or script request. The same leak reaches any site the user clicks through to. Search terms, account identifiers, order numbers and internal admin paths all travel this way. A cross-origin referrer also helps trackers stitch browsing together. strict-origin-when-cross-origin keeps the full URL for same-origin navigation, which analytics on your own site still needs, but sends only the scheme and host elsewhere. The security headers guide compares every value.
How to fix it
Pick strict-origin-when-cross-origin as the general default, or no-referrer / same-origin for applications where even your hostname is sensitive. nginx:
add_header Referrer-Policy "strict-origin-when-cross-origin" always;Apache:
Header always set Referrer-Policy "strict-origin-when-cross-origin"Express with Helmet (the default for helmet() is no-referrer; override if you rely on same-origin referrers):
app.use(helmet.referrerPolicy({ policy: 'strict-origin-when-cross-origin' }));A page-level alternative when you cannot change headers:
<meta name="referrer" content="strict-origin-when-cross-origin">Individual outbound links can be tightened further with rel="noreferrer". Cloudflare's Managed Transform "Add security headers" sets Referrer-Policy: same-origin at the edge. Whatever you choose, keep tokens out of URLs where possible: a reset token in a POST body or a short-lived cookie cannot leak through a referrer at all.
Where this fits
Referrer-Policy is check 7 of 13 that the website vulnerability scanner runs under http security headers, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Permissions-Policy (low), where no Permissions-Policy header restricts powerful browser features. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Referrer-Policy closes one route in. Immediately below it: Server version disclosure, where the Server header reveals the exact web server software and version, such as Apache/2.4.58 (Ubuntu) or nginx/1.24.0, which lets attackers and bots match it to known vulnerabilities without any probing; X-Content-Type-Options: nosniff, where responses lack X-Content-Type-Options: Nosniff, so browsers may guess a content type and execute a file as script or style when the server said it was something else; X-Powered-By technology disclosure, where an X-Powered-By or similar header announces the application platform and often its version (PHP/8.1.2, ASP.NET, Express), narrowing an attacker's search for applicable exploits.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Referrer-Policy (low severity)
Scanner check id: referrer-policyThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
