Verifiedapp Blog
Security Headers

Referrer-Policy: stop leaking your URLs to third parties

· 3 min read
#gdpr#privacy#referrer-policy#security-headers

The quiet leak in every link

When a visitor clicks a link from your page to another site, the browser attaches a Referer header telling the destination where the click came from. The same happens when your page loads an external image, script, font or analytics pixel. By default, that can be your full URL — path, query string and all.

Most of the time that is harmless. The problem is the times it is not: when your URLs contain things you did not mean to broadcast.

What actually ends up leaking

Full URLs leak more than people expect:

  • Tokens in query strings — password-reset links, magic-login links, signed URLs, session or invite tokens.
  • Private identifiers — internal IDs, account numbers, document references.
  • Revealing paths — /admin/, /internal/, /account/47213/invoice and similar, which tell an outside party about your structure and your users.

If any of those sit in a URL on a page that also loads third-party resources, the third party can receive them in the referrer. That is a data-exposure issue, and for personal data it is a privacy and GDPR concern too.

How Referrer-Policy fixes it

The Referrer-Policy header tells the browser exactly how much of the URL it may share. The values you will actually use:

  • no-referrer — send nothing, ever. Maximum privacy; can break analytics that rely on referrer.
  • same-origin — send the full referrer to your own site, nothing to others.
  • strict-origin-when-cross-origin — the modern default: full path within your origin, only your scheme-and-host to other origins, and nothing when downgrading from HTTPS to HTTP.
  • origin — always send just your origin, never the path.

For most sites, strict-origin-when-cross-origin is the right balance: you keep useful internal referrer data, and outside sites only ever learn that someone came from your domain — not the specific page or its query string.

Good news on the default

Modern browsers already use strict-origin-when-cross-origin as their built-in default when no policy is set, so you are not wide open by accident the way you once were. But relying on the browser default is fragile: it varies by browser and version, and setting the header explicitly makes the behaviour yours rather than the browser's. It is one line, so there is little reason not to.

How to set it

Add a response header, site-wide:

  • As an HTTP header: Referrer-Policy: strict-origin-when-cross-origin.
  • Or per-page with a <meta name='referrer'> tag, though the header is cleaner and applies everywhere.

You can also tighten individual links with rel='noreferrer' on an <a> tag when one specific link must reveal nothing.

Check what your pages reveal

You cannot see your referrer behaviour by reading your own site — it only shows up in the requests your visitors' browsers make to other servers. An automated scan reads your actual response headers and reports whether Referrer-Policy is set and sensible. Scan your site and confirm you are not handing your URLs to third parties.

Related reading

FAQ

What is the best Referrer-Policy value to use?
For most sites, 'strict-origin-when-cross-origin' is the right default. It keeps full referrer data within your own site but sends only your bare origin to other sites, so query strings and private paths never leave your domain.
Do I still need to set it if browsers default to a safe value?
It is still worth setting explicitly. The browser default can differ by browser and version, and an explicit header makes the behaviour predictable and yours. It is a single line of configuration, so the cost is negligible.
Can Referrer-Policy break my analytics?
Very strict values like 'no-referrer' can hide where traffic came from, which some analytics rely on. 'strict-origin-when-cross-origin' avoids that problem: outside services still see your domain as the source, just not the exact page or query string.

Keep reading