toolhq.io

All posts
4 min readby Jameel Haider

Referrer-Policy explained

When a visitor clicks a link or your page loads an external image, the browser often tells the destination where the request came from. It does this with the Referer header, misspelled since the early days of the web. On a plain page that is harmless, but a URL can carry a search query, a session token, or an internal path you did not mean to share. Referrer-Policy decides how much of that is sent.

What the Referer header leaks

The header contains the URL of the page that initiated the request. Consider a user on this page:

https://app.example.com/reset?token=abc123

If that page loads an analytics script or an image from another origin, the full URL, token included, can be sent to that third party in the Referer header. The same applies when the user clicks an outbound link. Anything in the path or query string is potentially exposed to wherever the request goes.

The policy values

Referrer-Policy lets you control this per response. The values range from sending nothing to sending everything:

  • no-referrer sends the header never. Maximum privacy, but you lose attribution data.
  • origin sends only the scheme and host, like https://app.example.com/, dropping the path and query.
  • same-origin sends the full URL to your own origin and nothing to others.
  • strict-origin sends the origin only, and nothing when downgrading from HTTPS to HTTP.
  • strict-origin-when-cross-origin sends the full URL to your own origin, just the origin to other origins, and nothing on a downgrade. This is the modern browser default.
  • unsafe-url always sends the full URL, including path and query, to everyone. The name is a warning.

The sensible default

Most browsers now apply strict-origin-when-cross-origin when no policy is set. It is a good balance: your own pages and your own analytics still receive full URLs for navigation data, while external parties get only your origin, so query strings and paths stay private. For most sites you do not need to override it.

Set it as a response header, or a meta tag when you cannot control headers:

Referrer-Policy: strict-origin-when-cross-origin

<meta name="referrer" content="strict-origin-when-cross-origin">

The privacy versus analytics tradeoff

Tightening the policy improves privacy but removes information your own tools may rely on. If your internal dashboards attribute traffic using the full referring URL, no-referrer will blind them. The practical middle ground is the default: keep full detail within your origin and leak only the bare origin outward. Reserve no-referrer for pages whose URLs carry secrets, such as password reset or invitation links.

Check what your site sends

You can confirm the header your server returns with the HTTP header viewer, which fetches a URL and lists every response header in the browser without sending anything to our servers. For the wider picture of security-related headers, see content security policy explained and HTTP headers explained.

The takeaway: leave the strict-origin-when-cross-origin default in place for most pages, and switch to no-referrer only where a URL itself is sensitive.