When a user clicks a link or a page loads a sub-resource, browsers send a Referer header (the historic misspelling) telling the destination which URL the request came from. The Referrer-Policy response header — or the referrerpolicy attribute on individual elements — controls how much of that URL is shared: the full path, just the origin, or nothing at all.
Why it matters
URLs frequently contain sensitive data: search queries, account IDs, password reset tokens, or session identifiers. Leaking them to third-party domains via Referer is both a privacy issue and a security risk — a tracking pixel on a page accidentally exposing a reset token can lead to account takeover. The W3C Referrer Policy specification recommends strict-origin-when-cross-origin, which most browsers also use as the default.
How to set it
- Send
Referrer-Policy: strict-origin-when-cross-originas a baseline. Cross-origin requests get only the origin; same-origin requests still get the full URL. - Use
no-referrerfor highly sensitive pages such as account or payment flows. - Avoid
unsafe-url, which sends the full URL to every destination regardless of scheme. - Override per-link with the HTML attribute, e.g.
<a href="..." referrerpolicy="no-referrer">. - Pair with HSTS, CSP, and a strict Permissions Policy for layered defence.
- Verify the header lands by inspecting responses in DevTools or running
curl -I.