--- 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 --- # Referrer-Policy Explained: what every outbound link tells strangers 2026-09-08 · WatchFor Team · Security · security, web, seo 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). --- Canonical page: https://watchfor.io/blog/referrer-policy-explained · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt