The Referer Header: How Your URLs Leak to Everyone You Link To

There is a field in nearly every web request that announces where you just came from. It is called the Referer header — misspelled in the original spec and never corrected — and by default it can carry the full address of the page you were on, query parameters included, to whatever site you click through to. For a single header, it leaks a surprising amount, and most sites never think to control it.

When you click a link, submit a form, or load an image from another domain, your browser attaches a Referer header telling the destination which URL initiated the request. It was designed for innocent purposes — analytics, debugging, letting a site know which inbound links drive traffic. But "the URL you came from" is rarely as innocuous as it sounds, because modern URLs are stuffed with information.

Why a URL is more sensitive than it looks

Consider what ends up in the path and query string of a real page: https://clinic.example/patients/results?case=cancer-panel&ref=A1742. Or a password-reset link, a one-time login token, a document share link, a search query, an account ID. When you navigate away from such a page — or when it loads a third-party script, font, or tracking pixel — the entire URL can be handed to the destination in the Referer header.

That means the third-party analytics provider, ad network, CDN, or external site you linked to may receive a URL that reveals a medical condition, a session token, the search you just ran, or simply the fact that you were on a specific private page. This is a quiet but real channel for metadata leakage, and it feeds directly into the real-time bidding ecosystem that profiles users by the pages they visit.

The classic failure

Putting a secret in a URL — a password-reset token, an invite code, a session identifier — is dangerous precisely because URLs travel. They land in Referer headers, browser history, server logs, and bookmarks. Secrets belong in the request body or a header you control, never the path or query string.

The Referrer-Policy header (spelled correctly this time)

The Referrer-Policy response header — note the correct double-r spelling, distinct from the misspelled Referer request header it governs — lets a site declare exactly how much referrer information browsers should send when leaving its pages. The values range from sending everything to sending nothing:

Policy value	What gets sent
`no-referrer`	Nothing, ever. Maximum privacy; breaks analytics that depend on referrers.
`same-origin`	Full URL to your own origin, nothing to cross-origin destinations.
`strict-origin`	Only the origin (scheme + host), and only when not downgrading HTTPS→HTTP.
`strict-origin-when-cross-origin`	Full URL within your own origin; only the bare origin when crossing to another site. The modern browser default.
`unsafe-url`	Always the full URL, even cross-origin and on downgrades. The name is a warning.

Modern browsers have shifted their built-in default to strict-origin-when-cross-origin, which is a meaningful improvement: cross-site requests now leak only your origin (e.g. https://clinic.example) rather than the full path and query. But "the default is better now" is not the same as "you are protected" — a site can still set unsafe-url, and you may want stricter behavior than the default provides.

Controls beyond the header

Referrer behavior can be tuned at several granularities, which is useful when a blanket policy is too coarse:

Per-page — the Referrer-Policy HTTP header, or a <meta name="referrer"> tag, sets the default for the whole document.
Per-element — a referrerpolicy attribute on an individual <a>, <img>, or <script> overrides the page default for that one request.
Per-link opt-out — rel="noreferrer" on a link strips the referrer entirely for that navigation (and also prevents the new page from accessing window.opener).

A solid default for a privacy-respecting site: set Referrer-Policy: strict-origin-when-cross-origin at minimum, or no-referrer if you have no need to send referrers at all — and never, under any circumstances, put a secret in a URL.

What it does and doesn't fix

Tightening your referrer policy stops your pages from leaking their URLs to the sites your users click through to or the third parties your pages embed. That is genuinely worth doing. What it cannot do is control what other sites send when they link to you, or substitute for the broader discipline of not embedding sensitive data in URLs and minimizing third-party content in the first place. Referrer policy is one tile in a mosaic that includes a strong Content Security Policy and a hard look at how much third-party JavaScript you load.

How Haven handles it

Haven's web surfaces ship a restrictive referrer policy alongside a strict CSP, and we treat URLs as non-secret by design — authentication and session state never ride in a query string where a stray Referer header could carry them off. The general rule we apply everywhere: assume any value placed in a URL will eventually be seen by someone you did not intend. If this was useful, our writeups on browser fingerprinting and cross-device tracking cover the rest of how the web quietly watches.