Safety
Referrer-Policy no-referrer vs strict-origin
June 14, 2025
Referrer-Policy no-referrer vs strict-origin is how much of the current URL the browser may put in Referer: no-referrer sends nothing, while strict-origin sends only the origin on HTTPS-to-HTTPS hops and nothing on a downgrade to HTTP. Most public sites want a cross-origin trim without killing same-origin full URLs — that is often strict-origin-when-cross-origin, not these two extremes. RoastMyOpsec grades that a Referrer-Policy header is present on the primary document; it does not score the token you chose, follow users off-site, or score GPC.
The practical difference
no-referrer is a mute button. Cross-origin analytics, CDN hotlink logs, and some payment or affiliate pixels that key off Referer get an empty story. It is the right control when paths or query strings must never leave, including to your own third-party tags.
strict-origin never sends path or query. Same-origin fetches also get origin-only, which is stricter than strict-origin-when-cross-origin (full URL same-origin, origin-only cross-origin HTTPS, nothing on downgrade). unsafe-url is the opposite miss. Header at the edge beats a meta tag that only some HTML routes remember.
How to choose based on what you shipped
Apps that still put reset tokens or invite codes in query strings should stop doing that, then set no-referrer or origin-only policies as defense in depth. Marketing sites that need outbound-click analytics usually start at strict-origin-when-cross-origin; step to strict-origin if same-origin paths should stay home too.
If a vendor demands full Referer, treat that as a data-sharing decision, not a default. Do not leave the header off and hope browser defaults stay kind.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| no-referrer | Tokens in URLs, high privacy, no Referer-dependent pixels | Some analytics and CDNs see an empty Referer | Maximum mute; fix query-string secrets anyway |
| strict-origin | You never want path or query in Referer, even same-origin | Same-origin full-URL analytics and some debug traces break | Origin-only everywhere HTTPS-to-HTTPS |
| strict-origin-when-cross-origin | Usual public-site default | Same-origin still sends path/query to your own hosts | Start here unless paths are sensitive on-origin too |
| unsafe-url | Almost never | Full URL, including to weaker contexts depending on policy | Do not ship on tokenized or account URLs |
When no-referrer still wins
no-referrer still wins on password-reset landings, magic-link bounce pages, and any HTML that might still carry a secret in the URL bar. strict-origin still wins when you need a vendor to see that traffic came from your origin without donating paths.
Neither policy stops your own server logs, the user's history, or a copy-pasted URL. Move secrets out of query strings first.
Common mistakes
The first mistake is no Referrer-Policy header and a comment that 'Chrome defaults are fine.'
The second mistake is no-referrer on the blog and unsafe-url on checkout because a pixel asked.
The third mistake is a tight policy on / and none on /blog/* behind a different CDN cache key.
What a URL roast can prove
RoastMyOpsec's free header audit flags a missing Referrer-Policy on the primary HTML response. It does not grade no-referrer versus strict-origin versus strict-origin-when-cross-origin, does not score Global Privacy Control (GPC), and does not crawl outbound links to see what Referer a partner received. Pair the header with honest URLs: tokens in query strings still leak through logs and history. The same pass still checks CSP quality, HSTS, framing, nosniff, Permissions-Policy, HTTPS scheme, session-like cookies, paths, and public JS secrets — header read only, no exploit payloads.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is no-referrer better than strict-origin?
- no-referrer donates less. strict-origin keeps origin-level analytics on HTTPS hops. Pick from the page's secrets and your measurement needs, not from a scanner's vanity score.
- Does RoastMyOpsec require a specific Referrer-Policy value?
- No. It checks that the header is present. Choosing no-referrer or strict-origin is your product decision.
- Does Referrer-Policy replace removing secrets from URLs?
- No. It only constrains the Referer header. History, logs, and screenshots still see the address bar. Do not put session material in query strings.