Referer

The Referer header (yes, misspelled — the 1996 HTTP spec set the canonical form to “Referer” and the typo became standard) is sent by browsers on most requests, containing the URL of the page the user was on when they triggered the request.

Used for:

• Web analytics — “where did this traffic come from?”
• Hot-link prevention — image hosts checking that requests originate from approved sites.
• CSRF defence-in-depth — some apps verify Referer matches the expected origin.
• Affiliate attribution — tracking which partner site drove a conversion.

Modern privacy concern: the full URL — including any tokens, search queries, or PII in the URL path — leaks to every third-party resource the page loads. The Referrer-Policy response header (note: correctly spelled this time) controls how much referrer information browsers send:

• no-referrer: never send a Referer header.
• same-origin: send full URL to same-origin requests, nothing to others.
• strict-origin-when-cross-origin: send origin only to cross-origin HTTPS requests. Modern browser default.
• unsafe-url: send full URL always. Avoid.

For privacy-sensitive applications, set a strict policy on every response.

The famous typo: the header was originally proposed in 1995 by Phillip Hallam-Baker, and the spec misspelled “Referrer” as “Referer” before the error was caught. By the time anyone noticed, several major implementations were already shipping. RFC 1945 froze the misspelling as canonical, and every browser since has had to use the wrong form for HTTP wire compatibility. When the W3C added a policy header in 2014, they deliberately spelled it correctly (Referrer-Policy) to differentiate it from the legacy request header.

What modern browsers send by default: as of Chrome 85 (Aug 2020), Firefox 87 (Mar 2021), and Safari 14, the default policy is strict-origin-when-cross-origin. Cross-origin requests now receive only the origin (https://example.com), not the full URL. Same-origin requests still get the full URL. This single change eliminated a decade of accidental URL-token leaks to third-party analytics and ad-tech scripts. For maximum-paranoia setups (banking, healthcare), set Referrer-Policy: no-referrer on every response — Convertitive’s production headers default to strict-origin-when-cross-origin. Reference: W3C — Referrer Policy.

Worked example: a password-reset URL leak

A common breach pattern: an app emails a password-reset link of the form https://app.example.com/reset?token=abc123def456.... The user clicks; the reset page loads and includes Google Analytics, Facebook Pixel, and a charting library from a CDN. Under the pre-2020 default policy each third-party request carried Referer: https://app.example.com/reset?token=abc123def456... — leaking the reset token to four different vendors’ server logs. Under the modern strict-origin-when-cross-origin default, the cross-origin requests carry only Referer: https://app.example.com and the token stays private. Even better, set Referrer-Policy: no-referrer on every sensitive-flow response — defence in depth costs nothing.

What still leaks despite policy

Referrer-Policy only governs the Referer header. URL tokens still appear in browser history, in the document.referrer JavaScript property visible to same-origin scripts, in window.location log statements, and in any error-monitoring SDK that captures URLs. The architectural fix is to put sensitive tokens in the request body or in a short-lived cookie set immediately on landing, then redirect to a URL without the token. Reference: RFC 9110 — HTTP Semantics §10.1.3 (Referer), which preserves the original misspelling in the canonical 2022 HTTP rewrite.