Missing Referrer-Policy

A missing Referrer-Policy header means the browser uses its default referrer behavior, which can leak the full URL of your pages — including paths, query parameters, and tokens — to third-party sites via the Referer request header.

What is Referrer-Policy?

Referrer-Policy is an HTTP response header that controls how much URL information the browser attaches to the Referer header when a user navigates away from your page, clicks an outbound link, or loads a cross-origin resource (images, scripts, fonts, analytics beacons).

When the header is absent, the browser falls back to its built-in default. Most modern browsers now default to strict-origin-when-cross-origin, but you should not rely on that — defaults vary by browser and version, embedded content and older clients can behave differently, and a missing header signals to scanners and auditors that referrer leakage hasn't been deliberately controlled. Setting the header explicitly removes the ambiguity.

The referrer policy is a small, low-risk security control: it doesn't break functionality, costs nothing, and closes a common information-leakage channel.

Why it's a risk / how it's exploited

The danger is information leakage. The Referer header is sent automatically by the browser and is visible to every destination your page links to or loads resources from — third-party analytics, ad networks, CDNs, embedded widgets, and any external site a user clicks through to.

Concrete scenario: a password-reset or email-confirmation link looks like https://app.example.com/reset?token=8f3a.... The user lands on that page, and it embeds a third-party analytics script or has an outbound link to an external site. With a permissive (or absent) policy, the browser sends Referer: https://app.example.com/reset?token=8f3a... to that third party. The reset token — meant to be secret — now sits in the third party's server logs and analytics dashboards. The same problem applies to session identifiers, invite links, API keys, and account IDs placed in URLs.

This isn't a remote-code-execution bug, but it's a real, recurring source of credential and PII exposure. Once a token leaks into someone else's logs, you can't recall it, and you usually won't know it happened.

How to detect it

Inspect the response headers for the Referrer-Policy field. From the command line:

curl -sI https://example.com | grep -i referrer-policy

If the command returns nothing, the header is missing. You can also open your browser DevTools, go to the Network tab, reload the page, click the document request, and look under Response Headers for Referrer-Policy.

To check the full set of response headers — including Referrer-Policy, X-Frame-Options, and CSP — in one pass, run the security headers checker. For a broader picture of what else is exposed across your site, a full website vulnerability scan will flag missing security headers alongside other findings.

How to fix it

Set the header at the web-server or CDN layer. A good general-purpose value is strict-origin-when-cross-origin: it sends the full URL only for same-origin requests, sends just the origin (scheme + host) on cross-origin HTTPS requests, and sends nothing when downgrading to HTTP. If your pages never need to send any referrer, use no-referrer.

nginx (inside the server block):

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

Apache (in the vhost or .htaccess, with mod_headers enabled):

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

Reload the server (nginx -s reload or apachectl graceful), then re-run the curl -I check to confirm the header is present. Apply it site-wide so every page — especially ones that carry tokens or IDs in the URL — is covered.

As defense in depth, avoid putting secrets in URLs at all: send tokens in request bodies or short-lived, single-use links, and prefer cookies or headers for session data.

FAQ

Is strict-origin-when-cross-origin or no-referrer better? strict-origin-when-cross-origin keeps useful same-origin referrer data and is a safe default for most sites. Use no-referrer when you want to send nothing at all — for example on highly sensitive pages — but check that no internal analytics depends on the referrer first.

Browsers already default to a strict policy — do I still need the header? Yes. Defaults differ across browsers and versions, embedded and legacy clients can vary, and setting the header explicitly makes the behavior predictable and passes security audits.