Loading...
WebShield Audit
Low severity
Weak Referrer Policy
Controls how much data about "where the user came from" is sent to the next website they visit.
Business risk
Privacy Leak: If a user resets their password at `yoursite.com/reset-password?token=123` and then clicks a link to an external blog, that blog receives the full URL (including the token) in the Referrer header. They could potentially hijack the account. `strict-origin-when-cross-origin` fixes this by stripping the path/query parameters for external requests.
Technical details
This header is critical for sites with sensitive URL parameters. `no-referrer` is the most private but breaks analytics. `strict-origin-when-cross-origin` is the modern "safe default" used by most browsers today even if unset, but you should set it explicitly to ensure coverage.
How to detect it
Referrer-Policy ships as a response header or a `<meta name="referrer">` tag. Header takes precedence. Modern browsers default to `strict-origin-when-cross-origin` when the header is absent, but that default is a browser policy, not a guarantee - set it explicitly.
Read the header
curl -sI https://yourdomain.com | grep -i referrer-policyFind inline meta override
curl -s https://yourdomain.com | grep -i "meta name=\"referrer\""Common pitfalls
- Setting `no-referrer` globally. It blocks the Referer entirely, which breaks analytics attribution, some ad network tracking, and external-link reporting you may actually need.
- Using `unsafe-url`. It sends the full URL (including path and query) to every cross-origin destination. That leaks session tokens from password-reset URLs, invite links, and OAuth callbacks.
- Trusting the browser default. Modern browsers default to `strict-origin-when-cross-origin`, but older browsers and embedded WebViews default to `no-referrer-when-downgrade`. Setting the header explicitly removes the ambiguity.
- Mixing meta and header with conflicting values. The header wins, but the meta tag can confuse scanners. Pick one channel.
- Relying on `Referrer-Policy` as a privacy boundary for sensitive URLs. If a URL contains a token you do not want leaked, the fix is to not put the token in the URL (move it to a POST body, a cookie, or a header) - not to hope the Referer is stripped.
Remediation guide
External references
Frequently asked questions
Which value should I pick?
`strict-origin-when-cross-origin` is the safe default - it sends the full URL for same-origin requests, the origin only for cross-origin requests over HTTPS, and nothing when downgrading from HTTPS to HTTP. It preserves analytics while protecting URL contents.
Can I override the policy per link?
Yes. `<a href="..." referrerpolicy="no-referrer">` overrides the document policy for that one link. Useful for "leave our site" links to sensitive destinations.
Does it break analytics?
Usually no with `strict-origin-when-cross-origin` - analytics needs the origin, not the path. With `no-referrer`, yes, most attribution breaks. Test with your analytics provider before shipping.
Keep going
Verify your fix
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.