Glossary
Referrer-Policy
`Referrer-Policy` controls how much of the current page's URL is sent in the `Referer` header when a visitor follows a link or the page loads a resource from elsewhere. Without a policy, browsers apply their own default, and full URLs can carry information that was never meant to leave the site: search terms, reset tokens, internal identifiers, document names. It is one header and it removes a category of quiet disclosure.
What a full referrer can disclose
Query parameters, which routinely carry search terms, filter values, session identifiers and tracking data.
Path segments naming a document, an account, an order or an internal identifier.
Single-use tokens in reset and invitation links, which are sent to every third-party resource the page loads.
The fact of the visit itself: for an internal tool or an unlisted page, the URL is the secret.
All of this is sent automatically, to every origin the page links to or loads from, without anything in the page suggesting it.
The values worth knowing
`no-referrer` sends nothing, ever. The most private and the one that breaks referral analytics entirely.
`same-origin` sends the full URL within the site and nothing to other origins.
`strict-origin-when-cross-origin` — the default in current browsers — sends the full URL to the same origin, only the origin to other origins, and nothing when moving from HTTPS to HTTP.
`no-referrer-when-downgrade` was the old default and sends the full URL to every origin over HTTPS, which is the leaky behaviour.
`unsafe-url` sends everything everywhere. The name is the warning.
`origin` always sends just the origin, including to the same origin, which is stricter than the default within the site and simpler to reason about.
Choosing one
`strict-origin-when-cross-origin` is a reasonable site-wide default: other sites learn you sent the visitor without learning from where.
`same-origin` or `no-referrer` suit applications where URLs carry identifiers, which is most authenticated software.
A page containing a reset or invitation token should set `no-referrer` specifically, regardless of the site default.
The policy can also be set per element with a `referrerpolicy` attribute on a link or an image, which is useful for a single sensitive case.
How to check it
`curl -I https://example.com | grep -i referrer-policy` shows whether one is set.
In the browser, following a link to an external site and inspecting the request's `Referer` header shows the actual behaviour.
Review which URLs on the site carry information in their query strings or paths, since that is what determines how much the policy matters.
Check pages that load third-party resources: the referrer is sent on every such request, not only on navigation.
A policy can also be set in a `meta name="referrer"` element, which is useful when the server configuration is not yours to change, though the header is applied earlier and is preferable.
Frequently asked questions
- What is a good default Referrer-Policy?
- strict-origin-when-cross-origin for most sites. Applications whose URLs carry identifiers are better served by same-origin or no-referrer.
- Why is the header spelled differently from the Referer header?
- The original header name contains a misspelling that was standardised and kept. The policy header uses the correct spelling.
- Does the policy apply to images and scripts too?
- Yes. The referrer is sent on subresource requests as well as on navigation, which is how a token in a URL reaches third parties.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website