Definition · Security Headers
What is Referrer-Policy?
When a browser follows a link or loads a subresource, it traditionally tells the destination where the request came from, using the Referer header (the misspelling is historical). That is useful for analytics and for debugging broken links, and it is a steady source of information leakage, because the full URL of the originating page often contains more than the site intended to share.
Referrer-Policy, specified by the W3C, controls what is sent. It can be set as a response header, in a <meta> tag, or per element with the referrerpolicy attribute and rel="noreferrer".
The values
| Value | Sends |
|---|---|
no-referrer | Nothing, ever |
same-origin | Full URL to the same origin only |
origin | Only the scheme, host and port, to everyone |
strict-origin | Origin only, and nothing when downgrading HTTPS to HTTP |
origin-when-cross-origin | Full URL same-origin, origin cross-origin |
strict-origin-when-cross-origin | As above, and nothing on a downgrade |
no-referrer-when-downgrade | Full URL except on a downgrade |
unsafe-url | Full URL always, including cross-origin. Avoid |
Modern browsers apply strict-origin-when-cross-origin as the default when no policy is set, which is a reasonable baseline. Setting the header explicitly still matters: it makes the behaviour intentional and consistent across older clients, and it lets you choose something stricter.
What leaks without it
The risk lives in URLs that carry data. Password reset and email verification links, magic-link logins, signed download URLs, session or invite tokens in query strings, single-use API keys, document identifiers, internal hostnames and path structures on intranet applications, and search terms or customer references that amount to personal data. Any of these travels to every third-party domain the page references — analytics, fonts, embedded media, advertising — and into that party’s logs.
Recommended practice is strict-origin-when-cross-origin as a site-wide floor, and no-referrer on pages whose URLs are sensitive, such as reset and token-bearing flows. The more robust fix is not to put secrets in URLs at all, since referrer leakage is only one of the ways they escape — browser history, proxy logs and bookmarks are others.
SurfaceLoop reports a missing or weak Referrer-Policy as part of its security header checks across every host it finds.
Related concepts
See CSP, permissions policy, HSTS, X-Frame-Options, GDPR Article 32 and security headers.