Support Library

Referrer-Policy: Control What Your URLs Reveal

When someone clicks a link or a page loads an image, script or font from another site, the browser can tell that site which page the visitor came from. Referrer-Policy decides how much of that address is shared: all of it, just your domain, or nothing.

Author
CategoryWebsite Security
Length4 minute read
UpdatedNovember 1, 2026

The short answer

Send a policy that keeps full addresses on your own site and shares only your domain with others:

Referrer-Policy: strict-origin-when-cross-origin

This is also the default in current browsers, but setting it explicitly protects visitors on older browsers and makes your intent clear. Avoid unsafe-url and no-referrer-when-downgrade.

What leaks

The Referer header with a leaky policy and with strict-origin-when-cross-origin Top, with unsafe-url: a visitor is on a password reset page whose address contains a token. The page loads an analytics script and links to a help site. Both other sites receive the full address, token included, in the Referer header and can store it in their logs. Bottom, with strict-origin-when-cross-origin: the other sites only receive https://example.com/, so the path and token stay private. unsafe-url Visitor on a page /reset?token=8f3a… Loads or links out Analytics, help site Referer sent https://example.com/ reset?token=8f3a… Other site logs it Token now in their logs Paths, search terms and tokens leak Third parties can reuse links strict-origin-when-cross-origin Visitor on a page /reset?token=8f3a… Loads or links out Analytics, help site Referer sent https://example.com/ Other site sees Only your domain Full URLs stay on your own site Nothing is sent from HTTPS to HTTP The Referer header with a leaky policy and with strict-origin-when-cross-origin Top, with unsafe-url: a visitor is on a password reset page whose address contains a token. The page loads an analytics script and links to a help site. Both other sites receive the full address, token included, in the Referer header and can store it in their logs. Bottom, with strict-origin-when-cross-origin: the other sites only receive https://example.com/, so the path and token stay private. unsafe-url Visitor on a page /reset?token=8f3a… Loads or links out Analytics, help site Referer sent https://example.com/ reset?token=8f3a… Other site logs it Token now in their logs Paths, search terms and tokens leak Third parties can reuse links strict-origin-when-cross-origin Visitor on a page /reset?token=8f3a… Loads or links out Analytics, help site Referer sent https://example.com/ Other site sees Only your domain Full URLs stay on your own site Nothing is sent from HTTPS to HTTP
The Referer header can carry everything in the address bar. The policy decides how much of it leaves your site.

How DNS Panopticon detects it

Security Posture reads the Referrer-Policy header on your homepage. A policy can list fallbacks separated by commas; like browsers, the check uses the last value it recognises. The result appears on the Website Application Security card.

FindingSeverityWhen it appears
Referrer-Policy shares full URLsLowThe policy is unsafe-url or no-referrer-when-downgrade, which send the full address to other sites.
No Referrer-PolicyLowNo policy is set, so browser defaults decide.
Referrer-Policy is setPassAny other valid policy.

How to check it yourself

CommandWhat to look for
curl -sI https://example.comA referrer-policy line and its value.

A page can also set a policy with <meta name="referrer" content="…">, or per link with a referrerpolicy attribute. In developer tools, select a request to another site in the Network tab and look at its Referer request header to see what is actually sent.

The policy values

ValueSent to your own siteSent to other sites
no-referrerNothingNothing
same-originFull URLNothing
strict-originOrigin onlyOrigin only; nothing from HTTPS to HTTP
strict-origin-when-cross-originFull URLOrigin only; nothing from HTTPS to HTTP (the browser default)
originOrigin onlyOrigin only, even from HTTPS to HTTP
origin-when-cross-originFull URLOrigin only, even from HTTPS to HTTP
no-referrer-when-downgradeFull URLFull URL, except from HTTPS to HTTP (flagged)
unsafe-urlFull URLFull URL, even to HTTP sites (flagged)

The origin is the scheme, host and port, for example https://example.com/. The full URL adds the path and query string, but never the part after #.

Why it matters

  • Tokens in URLs. Password reset links, magic sign-in links, shared document links and some session IDs live in the address. Sending them to analytics or ad networks hands them to third parties.
  • Private information in paths. Search terms, order numbers and pages such as /patients/1234 reveal more than a domain name.
  • Privacy laws. Leaking personal data in URLs to third parties can count as an unintended disclosure under laws such as GDPR.

A missing policy is rated low because current Chrome, Edge, Firefox and Safari already default to strict-origin-when-cross-origin. A leaky policy is worse than none, because it overrides that safe default.

How to fix it

  1. Pick a policy. strict-origin-when-cross-origin suits most sites. Use same-origin or no-referrer for sensitive applications such as health, finance or admin areas.
  2. Remove leaky values left by old plugins or templates, including in meta tags.
  3. Keep secrets out of URLs where you can: send tokens in POST bodies or headers, and make links single-use and short-lived.
PlatformSetting
nginxadd_header Referrer-Policy "strict-origin-when-cross-origin" always;
ApacheHeader always set Referrer-Policy "strict-origin-when-cross-origin" (needs mod_headers)
IISIn web.config, under system.webServer/httpProtocol/customHeaders: <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
CloudflareRules → Transform Rules → Modify Response Header, set the header on all requests
NetlifyIn _headers: a /* line, then Referrer-Policy: strict-origin-when-cross-origin indented below it
Application codeMiddleware such as Helmet (Express) or the response headers settings of your framework

If one partner genuinely needs full URLs, set referrerpolicy on those specific links instead of loosening the policy for the whole site.

FAQ

Why is the header spelled Referer but the policy Referrer?

The Referer request header was misspelled in the original HTTP specification and kept for compatibility. The newer Referrer-Policy header uses the correct spelling.

Will a strict policy break analytics?

Your own analytics still see full paths for navigation within your site. Third-party tools see which domain sent the visitor, which is usually all they need. no-referrer can hide campaign sources from other sites you link to.

Does it matter if browsers already default to a safe policy?

Setting it explicitly covers older browsers and embedded web views, and stops a plugin or template from quietly switching to a leaky value.

Sources and further reading

Related support articles

Content-Security-PolicyClickjacking and frame-ancestorsX-Content-Type-Options: nosniffHTTPS and HTTP-to-HTTPS Redirects