When a browser follows a link or loads a resource, it may send a Referer request header telling the destination which page initiated the request. Referrer-Policy lets a website control how much of that source address is shared.
The policy is a privacy and information-disclosure control, not a trust badge. A sensible setting can reduce unnecessary exposure of page paths and query strings while preserving enough origin information for legitimate analytics and troubleshooting.
Referrer-Policy controls the contents of the outbound Referer request header. The request-header name is misspelled for historical reasons, while the policy header uses the correctly spelled word referrer.
The decision depends on the destination and the selected directive. Same-origin requests can be treated differently from cross-origin requests, and HTTPS-to-HTTP downgrades can be prevented from receiving referrer information.
Modern browsers generally use strict-origin-when-cross-origin when a website does not declare another policy. For same-origin requests it can send the full referring URL; for a cross-origin request it sends only the origin; and it sends no referrer on a downgrade from HTTPS to HTTP.
An explicit Referrer-Policy header still has value because it documents the site's decision and avoids relying on an implicit browser default. It also makes review and change control easier when a hosting platform, proxy or application framework changes.
Common choices include no-referrer, same-origin, strict-origin, origin-when-cross-origin and strict-origin-when-cross-origin. The right choice depends on whether the site needs referral detail across its own pages, across trusted domains or for third-party analytics.
Avoid unsafe-url unless there is a carefully reviewed requirement, because it can send the full path and query string on cross-origin requests. Even with a restrictive policy, sensitive values should not be placed in URLs: browser history, logs, screenshots and other channels can expose them.
The most consistent approach is an HTTP response header applied centrally by the application, web server, content delivery network or reverse proxy. A meta element can set a document policy, and individual links or requests can use a referrerpolicy attribute, but scattered overrides are harder to audit.
Roll the change through a test environment first. Confirm that payment providers, analytics, sign-on callbacks and other integrations do not depend on more referrer detail than the proposed policy will provide, then document the chosen directive and its owner.
Open browser developer tools, reload the page and inspect the main document response for the Referrer-Policy header. Then follow representative same-origin and cross-origin links and inspect their request headers to confirm the observed Referer value matches the intended policy.
Test redirects as well as direct navigation, and repeat the check after hosting, proxy or framework changes. A header can disappear when responsibility moves between layers even if the application code did not change.
Referrer-Policy reduces one form of information disclosure. It does not replace Content-Security-Policy, transport security, access control, secure application code or careful URL design, and it cannot decide whether a destination is trustworthy.
Treat it as one browser-facing layer in the wider security-headers set. The security-headers hub explains how it complements controls for framing, content loading, MIME sniffing and HTTPS enforcement.
ScoutLab's Free Scan can observe whether a public website returns a Referrer-Policy header and report its absence as an item to review. The check does not log in, change the site's configuration or prove that a chosen directive suits every application workflow.
ScoutLab does not detect malware or blacklist status through this check, does not perform a manual penetration test, does not provide compliance certification, and cannot guarantee privacy or security. Configuration decisions and remediation remain with the website owner and their technical provider.
The Free Scan observes externally visible website and domain signals, including whether Referrer-Policy is present. It does not change configuration or guarantee security.
Run the free website security checkAn explicit policy is useful because it records the site's intended behaviour instead of relying on a browser default. The selected directive should still be tested against analytics, payments, sign-on and other integrations.
Not in every case. It can send the full URL to the same origin, sends only the origin to a different HTTPS origin, and sends nothing on an HTTPS-to-HTTP downgrade.
It can reduce cross-origin disclosure, but secrets should not be placed in paths or query strings. URLs can also appear in browser history, logs, screenshots and other systems outside the policy's control.
No. ScoutLab can observe the public header and explain the finding, but it does not automatically change application, hosting, proxy or content-delivery configuration.
Website security is layered. External checks can surface useful public signals, but secure development, patching, access control, backups and appropriate testing remain separate responsibilities.
