--- title: Referrer-Policy Explained: what every outbound link tells strangers description: Click a link on your site and the browser quietly tells the destination which page you came from — the full URL, including whatever is in it. Sometimes that's a reset token. One header decides how much gets sent. canonical: https://watchfor.io/blog/referrer-policy-explained --- [All posts](/blog) [Security](/blog/category/security) Sep 08, 2026 · 4 min read · WatchFor Team # Referrer-Policy Explained: what every outbound link tells strangers Click a link on your site and the browser quietly tells the destination which page you came from — the full URL, including whatever is in it. Sometimes that's a reset token. One header decides how much gets sent. Someone is on this page of your app: https://app.example.com/invoices/8891?email=maria@customer.com&token=9f2c... They click a link to a documentation site. The browser sends that entire URL — path, query string, token and all — to the other site, in a header called Referer , without asking anyone. That's the default. It has been for thirty years, and it's why Referrer-Policy exists. ## Who actually receives it Not just the site you linked to. The referrer goes out with every request the browser makes to somewhere else , which on a typical page means: - The site behind each outbound link, when someone clicks it. - Every third-party script, font, stylesheet and image the page loads. - Every analytics, chat, ads or error-reporting vendor you use. So the URL of the page a customer is looking at is routinely handed to a handful of companies, and then sits in their logs. Nobody attacked you. This is the documented behaviour of the web. ## Why that's a problem on URLs like yours Look at what real applications put in a URL: - Password reset and magic-link tokens — ?token=… . If the reset page loads any third-party script, that token goes to a stranger's server while it's still valid. - Email addresses and customer IDs — often in query strings for convenience. - Search terms — including the ones people type into a support search box when something has gone badly wrong. - Internal structure — /admin/… , /beta/… , /customers/8891/contracts/… . Not a secret exactly, but not something to hand out either. - Document and invoice identifiers that are guessable once you've seen a few. And on HR, health, legal or finance sites, the path itself is often the sensitive part. /policies/redundancy-consultation leaks its meaning before anyone reads a byte of it. ## Nothing looks wrong, again Your site works. There's no error and no warning. The leak is a header on a request you didn't know was being made, arriving somewhere you can't see. That's exactly why it turns up as a finding in a [website audit](/smart-website-audit) on a site with nothing else wrong. ## The fix Referrer-Policy: strict-origin-when-cross-origin This is the modern default in most browsers, which means setting it explicitly costs you nothing and guarantees the behaviour rather than hoping for it. It says: - Same-site navigation: send the full URL. Your own analytics still work. - Cross-site: send only the origin — https://app.example.com , no path, no query. - HTTPS to HTTP: send nothing at all. The other values, from loosest to strictest: Value What leaves your site unsafe-url Everything, always. Never use this. no-referrer-when-downgrade Full URL, except HTTPS→HTTP. The old default. origin Only the origin, even internally. strict-origin Origin, and nothing on a downgrade to HTTP. strict-origin-when-cross-origin Full URL internally, origin externally. The sensible default. no-referrer Nothing, ever. ## Won't this break my analytics? This is the honest question, and the answer is mostly no: - Your own analytics keep the full referrer, because same-origin navigation is unaffected by the recommended value. - Referral reports in other people's analytics still see your origin, so you keep the attribution — a partner still knows traffic came from you, just not which page. - Affiliate and ad networks occasionally want the full URL. If one genuinely does, that's a conversation with them, not a reason to leak every page to everyone. - SEO is unaffected. Search ranking doesn't use the referrer header. If a specific link needs different treatment, you can set it per-element: . ## The better fix underneath A policy limits the damage; it doesn't make the URL safe. If something is genuinely secret, it should not be in a URL at all — URLs end up in browser history, server logs, proxy logs, bookmarks, screenshots and chat messages, none of which respect your header. - Put tokens in a POST body or exchange them for a session immediately on arrival. - Make reset tokens single-use and short-lived, so a leaked one is already dead. - Keep third-party scripts off pages that carry sensitive parameters. ## Keeping it there One header, easy to lose in a proxy rewrite, invisible when it goes. Check what your site sends with the free [HTTP header checker](/http-header-checker), or run the [Smart Website Checker](/smart-website-audit) for all six at once. An [API monitor](/docs/monitors/api) can assert it on every check if you'd rather be told than reminded. ## The bottom line In one line What A header controlling how much of your URL is sent to other sites. Why The default hands full URLs — tokens, emails, internal paths — to every third party. Danger without it A live password-reset token in someone else's access log. Add Referrer-Policy: strict-origin-when-cross-origin . Better still Keep secrets out of URLs entirely. This one takes about a minute, breaks essentially nothing, and stops your application quietly narrating itself to every vendor on the page. Related: [Content Security Policy explained](/blog/content-security-policy-explained), [Permissions-Policy explained](/blog/permissions-policy-explained), [Clickjacking explained](/blog/clickjacking-explained). [#security](/blog/tag/security)[#web](/blog/tag/web)[#seo](/blog/tag/seo) ## Monitor your website & APIs Continuous HTTP/HTTPS checks with status-code, latency and content assertions — plus instant alerts when something breaks. [Learn more](/http-monitoring)[Start free](/auth/sign-up) Share this article --- Canonical page: https://watchfor.io/blog/referrer-policy-explained · Site guide: https://watchfor.io/llms.txt