Overview
The Referrer-Policy header controls how much referrer information the browser sends when users navigate away from your site, protecting against leaking sensitive data in URLs. This capstone lesson covers it and consolidates security headers.
Learning objectives
- Explain the referrer and its privacy/security risk.
- Describe what Referrer-Policy controls.
- Consolidate the security-headers checklist.
Core concept
When a user follows a link or a page loads a resource, the browser may send a Referer header telling the destination which URL the request came from. If your URLs contain sensitive data (tokens, identifiers, internal paths), this can leak to third parties. The Referrer-Policy header controls how much referrer information is sent — from full URL, to origin only, to none — across same-origin vs cross-origin and HTTPS→HTTP transitions. A common safe choice is strict-origin-when-cross-origin (send full referrer same-origin, only the origin cross-origin, and nothing on downgrade to HTTP).
How it works
The browser applies your Referrer-Policy to decide what to put in the Referer header for outgoing requests and navigations. A restrictive policy ensures that when users click links to external sites (or your pages load third-party resources), the full URL — which might embed sensitive values — is not disclosed; instead only the origin, or nothing, is sent. This prevents inadvertent leakage of tokens or private paths via referrers. It also reinforces the broader principle: don't put sensitive data in URLs in the first place (they are logged, cached, and shared), with Referrer-Policy as an additional safeguard.
Practical example
A site sets Referrer-Policy: strict-origin-when-cross-origin. When a user clicks an external link from a page whose URL contains a sensitive parameter, the browser sends only the site's origin (not the full URL) to the external site — so the sensitive parameter is not leaked in the Referer. On downgrade to HTTP, no referrer is sent at all. Combined with keeping sensitive data out of URLs, this prevents referrer-based disclosure.
Cybersecurity relevance
Referrer leakage can disclose sensitive tokens or internal URLs to third parties, a privacy and security concern; Referrer-Policy mitigates it and is a recommended header. It consolidates the security-headers module, which together form a standard hardening set: CSP (restrict content/execution), HSTS (force HTTPS), X-Content-Type-Options (no MIME sniffing), frame protections (anti-clickjacking), and Referrer-Policy (limit referrer leakage), plus protective cookie flags. Missing or weak headers are among the most common assessment findings; applying the full set is cheap, high-value hardening.
Common mistakes
- Putting sensitive data in URLs and relying on Referrer-Policy alone to protect it.
- Not setting a restrictive Referrer-Policy, leaking full URLs cross-origin.
- Treating security headers as optional rather than a standard baseline.
Key takeaways
Referrer-Policycontrols how much referrer (source URL) information the browser sends, preventing leakage of sensitive data in URLs (e.g.strict-origin-when-cross-origin).- It complements the rule to keep sensitive data out of URLs entirely.
- The security-headers baseline — CSP, HSTS, X-Content-Type-Options, frame protections, Referrer-Policy, plus cookie flags — is cheap, high-value hardening; missing headers are common findings.
Check your understanding
- How can the
Refererheader leak sensitive information, and how doesReferrer-Policyhelp? - Name the core security headers that form a standard hardening baseline and what each does.