blueredix logo
low missing-referrer-policy

Referrer-Policy not set

Without a Referrer-Policy header, visitors leak the full URL (including tokens, search terms, IDs) to every external site they click. The one-line fix.

What this means in plain English

Whenever your visitor’s browser loads anything on a page — an image, a script, a font, a link they click — it tells the destination where the request came from. That information is called the referrer. By default, browsers attach the page’s URL (or part of it) to every outgoing request.

Without a Referrer-Policy instruction, browsers fall back to a reasonable but not strict default. On older browsers and in some older user agents, the default is even more permissive: send the full URL, including any query string or path that may be sensitive.

Why it matters to your business

Most pages on a website have URLs that are perfectly fine to leak — /about, /products, /contact. The problem is the small number of URLs that aren’t:

  • Password-reset links and magic-login links contain a one-time token in the URL.
  • Authenticated dashboards may have URLs that reveal the structure of your admin area.
  • Shareable links to private documents often encode access in the URL itself.

If any of those pages loads a third-party script, font, or image, the third party’s logs may end up containing a working reset token, a private document URL, or sensitive search terms. This has been a real issue at major SaaS vendors (HubSpot, Atlassian, others) within the last few years.

A Referrer-Policy is a one-line backstop that prevents most of this leakage with no functional impact on your site.

How to fix it

Whoever runs your web server adds a single instruction. The standard recommended choice:

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

This sends the full URL only on requests within your own site, just the bare domain (no path) on cross-site requests over HTTPS, and nothing at all if a downgrade to plain HTTP would be involved. It matches modern browser defaults and is what OWASP recommends.

Stricter alternatives if you don’t need referrer information:

  • same-origin — sends a referrer only to your own site, never to third parties.
  • no-referrer — never sends a referrer. Breaks some affiliate tracking and analytics that depend on referrer information; safe for sites with no marketing tooling that needs it.

Common server snippets:

nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

Caddy:

header Referrer-Policy "strict-origin-when-cross-origin"

A Referrer-Policy is a useful safety net, but the better long-term fix is to not put tokens in URLs in the first place. If you have flows that send a one-time token in a URL (password reset, magic-link login, share-by-link), the receiving page should remove the token from the URL as soon as it loads — that way it never ends up in browser history, bookmarks, or referrer headers in the first place. Whoever wrote that part of your application can do this in a few lines.

Further reading