How to set Referrer-Policy to prevent URL leakage?

referrer-policy-missingglobal

Referrer-Policy controls how much URL information the browser sends in the Referer header when navigating to another page or loading external resources. Without a policy, the browser decides what to send. Older browsers default to sending the full URL, including path, query parameters, and fragments. This exposes internal URL structures, search queries, session tokens in URLs, and authenticated paths to any destination server or intermediary.

What’s wrong

No Referrer-Policy header is present in the HTTP response. The browser falls back to its default behavior, which varies by engine and version. Modern browsers default to strict-origin-when-cross-origin, but older browsers send the full URL including path and query string. A site relying on browser defaults has no control over what referrer data leaves the origin. The behavior changes silently across browser updates and cannot be audited from server-side logs alone.

Why it matters

The Referer header carries the full or partial URL of the page initiating a request. On sites where URLs contain meaningful state — search queries, user IDs, token parameters, internal path structures, preview slugs, admin routes — this data reaches every external resource loaded by that page. Analytics scripts, CDN providers, embedded widgets, and outbound link destinations all receive it. Query strings are the most common leak vector. Password reset tokens, OAuth state parameters, and session identifiers placed in URLs are transmitted to third parties without any user action beyond navigating away. Even path-only leaks reveal internal information architecture to competitors and scrapers.

The correct change

Set a Referrer-Policy header that limits referrer data to what external destinations actually need. strict-origin-when-cross-origin is the recommended default for most sites. It sends the full URL for same-origin requests, sends only the origin for cross-origin requests over HTTPS, and sends nothing when downgrading from HTTPS to HTTP. For pages handling sensitive data — login, account management, admin panels — use no-referrer or same-origin to prevent any external leakage. Apply the header globally at the server or CDN level, then override on specific routes where stricter policies are required.

Available policy values

• Each policy value controls a different trade-off between privacy and functionality:
• no-referrer — Sends no Referer header at all. Maximum privacy. Breaks analytics that rely on referrer data for traffic attribution.
• no-referrer-when-downgrade — Sends the full URL for same-protocol requests (HTTPS to HTTPS) and nothing when downgrading (HTTPS to HTTP). This was the legacy browser default.
• origin — Sends only the origin (scheme + host + port) without any path or query information. Cross-origin destinations see which domain the request came from but nothing more.
• origin-when-cross-origin — Sends the full URL for same-origin requests and only the origin for cross-origin requests. Preserves same-origin analytics while limiting external exposure.
• same-origin — Sends the full URL for same-origin requests and nothing for cross-origin requests. External destinations receive no referrer data at all.
• strict-origin — Sends the origin for same-protocol requests and nothing when downgrading. A protocol-aware variant of origin.
• strict-origin-when-cross-origin — Sends the full URL for same-origin, the origin for cross-origin same-protocol, and nothing on downgrade. This is the recommended general-purpose default.
• unsafe-url — Always sends the full URL including path and query string to every destination. Provides no privacy protection. Avoid in production.

Scope

This condition applies globally. The Referrer-Policy header should be set on all responses, typically at the server or CDN configuration level. Individual pages with heightened sensitivity — authentication flows, account settings, admin interfaces — should override the global policy with stricter values like no-referrer or same-origin. The policy also affects resources loaded by the page: scripts, stylesheets, images, and fetch requests all inherit the referrer policy unless overridden at the element or request level.

How to verify

• Validation confirms the condition is resolved:
• Referrer-Policy header present in HTTP responses
• Policy value is strict-origin-when-cross-origin or stricter
• Cross-origin requests send only the origin, not the full URL path
• HTTPS-to-HTTP navigations send no referrer data
• Sensitive pages (login, account, admin) use no-referrer or same-origin
• Third-party scripts and embeds do not receive URL paths or query parameters
• Browser DevTools Network tab confirms correct Referer header values on outbound requests

Takeaway

• Referrer-Policy prevents URL information from leaking to external destinations
• strict-origin-when-cross-origin is the balanced default — it preserves same-origin analytics while limiting cross-origin exposure to the origin only
• Sensitive pages should use no-referrer or same-origin to eliminate external leakage entirely
• Relying on browser defaults leaves referrer behavior inconsistent across browser versions and provides no auditable guarantee

FAQ

Why not just use no-referrer everywhere?

no-referrer eliminates all referrer data, including same-origin referrers used by internal analytics, CSRF protection mechanisms, and server-side logging. Applications that track navigation paths, attribute internal conversions, or validate request origins lose that signal entirely. strict-origin-when-cross-origin preserves same-origin referrer data while restricting cross-origin leakage to the origin only.

Does Referrer-Policy affect analytics tracking?

It can. Third-party analytics tools that rely on the Referer header for page-level traffic attribution receive less data under strict policies. With strict-origin-when-cross-origin, external analytics see which domain sent the request but not which page. First-party analytics on the same origin still receive the full URL. Most analytics platforms have adapted to use JavaScript-based tracking that does not depend on the Referer header.

Can Referrer-Policy be set per element instead of globally?

Yes. HTML elements accept a referrerpolicy attribute, and fetch requests accept a referrerPolicy option. These override the document-level policy for specific resources. This is useful for embedding third-party widgets that require referrer data while maintaining a strict global policy. The global header sets the baseline; element-level attributes provide targeted exceptions.

What is the difference between Referrer-Policy and the Referer header?

Referrer-Policy is a response header set by the server to control browser behavior. The Referer header is a request header sent by the browser when navigating or loading resources, containing the URL of the referring page. Referrer-Policy governs what value the browser places in Referer. The misspelling of Referer (missing double r) is a historical artifact preserved for backward compatibility.

Do modern browsers already default to strict-origin-when-cross-origin?

Chrome 85+, Firefox 87+, Safari 15+, and Edge 85+ default to strict-origin-when-cross-origin when no policy is set. However, relying on browser defaults means the policy is invisible in server configuration, cannot be audited or enforced centrally, and fails silently in older browsers or non-standard clients. Setting the header explicitly makes the policy declarative and verifiable.

Does Referrer-Policy protect against all URL leakage?

No. It controls only the Referer request header. URLs can also leak through server logs, browser history, cached pages, the Origin header on CORS requests, and JavaScript APIs like document.referrer. Referrer-Policy addresses the most common and automated leak vector but is not a substitute for keeping sensitive data out of URLs entirely.

The fix

Prevent URL information leakage by setting a Referrer-Policy header that limits referrer data sent to external destinations

Done when: Referrer-Policy is set to strict-origin-when-cross-origin or stricter on all responses, with sensitive pages using no-referrer or same-origin

Do not

• Do not use unsafe-url which sends full URLs to all destinations
• Do not rely on browser defaults without an explicit header
• Do not place sensitive data in URL query parameters regardless of referrer policy
• Do not assume all browsers share the same default referrer behavior

How to verify

• Referrer-Policy header present in HTTP responses
• Policy value is strict-origin-when-cross-origin or stricter
• Cross-origin requests do not include URL paths or query strings
• HTTPS-to-HTTP transitions send no referrer data
• Sensitive pages enforce no-referrer or same-origin

Find every page with this

probeo monitors this continuously across every page of your site, and records which pages passed, which failed, and which it could not determine.