Missing Referrer-Policy Header
Last updated August 11, 2026.
What this finding means
Your site does not send a Referrer-Policy header. Without it, browsers fall back to their own default behavior for what to include in the Referer header when a user navigates away from your site — and that default can send more of the URL than you intend to whichever site the user lands on next.
Why it matters
URLs often carry more than a path — session identifiers, search terms, internal document IDs, password-reset tokens in query strings. Without a policy, browsers may send the full referring URL to every link a user clicks, including third-party sites and analytics tools, leaking that information off your domain. `strict-origin-when-cross-origin` (the current browser default, but worth setting explicitly) sends the full URL only to same-origin requests and just the origin to cross-origin ones, dropping it entirely on an HTTPS-to-HTTP downgrade.
What Nivaronix checks
Nivaronix's security headers checker inspects the response headers your site sends and reports whether Referrer-Policy is present. This is a security misconfiguration check based on the header's presence and configuration — not a vulnerability scan, exploit attempt, or penetration test.
Evidence example
Example only, for illustration — not evidence from a live scan of any specific site.
HTTP/1.1 200 OK
(no Referrer-Policy header present)How to fix it
Nginx
add_header Referrer-Policy "strict-origin-when-cross-origin" always;Apache
Header always set Referrer-Policy "strict-origin-when-cross-origin"Cloudflare
Rules → Transform Rules → Modify Response Header → set `Referrer-Policy` to `strict-origin-when-cross-origin`.Verify the fix
Re-run a scan on your domain, or check manually with curl -sI https://your-domain.example, and confirm Referrer-Policy now appears in the response with the expected value.
FAQ
If the browser has a safe default, why does the missing header still matter?
strict-origin-when-cross-origin is the modern browser default, but a site can't rely on every visitor running a current browser, and the default can change or vary between browser engines. Setting the header explicitly guarantees the behavior regardless of which browser or version a visitor uses, rather than depending on an assumption about defaults.
What kind of data actually leaks without this header?
Anything present in the URL's path or query string on the page a visitor is leaving — session identifiers, search terms, internal document IDs, or password-reset tokens are the concrete examples this matters for. A permissive referrer behavior sends that full URL to whatever third-party site or resource the browser loads next.
Does this finding mean my site is actively leaking data right now?
It means the browser has no explicit instruction from your site about referrer behavior, so it falls back to its own default — which for most current browsers is already reasonably safe. The finding flags the absence of an explicit, guaranteed policy, not a confirmed active leak.
Is Referrer-Policy a CSP directive or a separate header?
It's a separate, standalone HTTP response header — unlike frame-ancestors, which lives inside Content-Security-Policy. Referrer-Policy has its own header name and is set independently of any CSP configuration your site has.
Standards reference
MDN — Referrer-Policy. See the methodology page for exactly how this finding is scored.