Referrer-Policy controls how much referring-page information a browser sends with supported requests. It is useful when a website links to other services or loads third-party resources, because a page URL can contain private context that the destination does not need. The policy limits a particular browser disclosure path; it does not make a sensitive URL safe everywhere.
This guide explains how to choose and verify a policy for a website you operate. Start with the information your URLs contain and the requests your pages make, rather than copying a header solely because a scanner recommends it.
Define the Referrer-Policy privacy goal
List the places where users arrive with private information in the URL. Account identifiers, search terms, campaign data, and temporary authorization material deserve different handling. Identify which of those values should not be sent to another destination.
Map outbound links, images, scripts, embedded content, and other browser requests. A disclosure can occur through a resource request as well as a deliberate click. The practical question is which destinations need which information.
Document the policy owner and business requirements. Analytics convenience should not silently override the protection required for customer or account data.
Remove sensitive data from URLs first
Avoid placing secrets or unnecessary personal information in query strings and paths. URLs can appear in logs, history, bookmarks, screenshots, and copied messages independently of referrer behavior. A browser policy cannot erase those other routes.
If a workflow uses a temporary token in a URL, review the complete lifecycle and supported security controls. Limit exposure and lifetime according to the feature’s requirements instead of assuming a no-referrer setting makes the design harmless.
Use synthetic values when testing. A privacy review should not create additional copies of live credentials merely to prove that a request contains them.
Understand the main policy choices
Policies differ in whether they send no referrer, only an origin, or more URL information under particular conditions. An origin identifies the scheme, host, and port, while a fuller referring URL can disclose path and query context.
A policy such as strict-origin-when-cross-origin distinguishes same-origin and cross-origin requests and includes downgrade-related restrictions. Do not summarize its behavior as never sharing a URL or always sharing only a domain.
Use the MDN Referrer-Policy reference for exact directive meanings. Browser support and applicable request contexts should be verified for the clients your application serves.
Choose a policy that matches the workflow
A website may prefer a strict global policy and deliberate exceptions, or another documented configuration supported by its requirements. Choose based on actual disclosure needs, not an abstract rule that the most restrictive option is always compatible with every integration.
If an external service claims to need referrer information, establish what it actually requires. An origin may suffice where a full private path is unnecessary. Prefer redesigning a brittle integration over exposing secrets to keep it working.
Keep the decision understandable. Record the information permitted for same-origin requests, cross-origin requests, and relevant transitions so another developer can review it without interpreting an unexplained header.
Configure the intended delivery mechanism
Review the supported response-header, document, and element-level mechanisms relevant to your site. They can have different scopes and precedence. A page-level setting is not proof that every resource or navigation uses the same effective policy.
Check reverse proxies, CDNs, and application middleware for conflicting configuration. Multiple layers can add or replace headers. Inspect the deployed response rather than assuming a local template describes the final browser behavior.
Treat policy changes as application configuration with review and rollback. A change can affect third-party analytics or workflows, so verify those consequences without weakening unrelated privacy requirements.
Test what the browser actually sends
Use a controlled page and destinations you administer. Inspect requests from same-origin navigation, cross-origin links, and representative resources. Confirm whether the observed referrer matches the chosen directive and the relevant request context.
Test supported browsers and the actual deployed protocol arrangement. A result from one client or a local HTTP page may not represent the production HTTPS workflow. Capture safe evidence and avoid collecting unrelated browsing traffic.
Do not rely only on a response-header screenshot. The useful outcome is the information the destination receives for the tested request, with the source and policy context documented.
Keep related browser controls separate
Referrer policy does not decide whether third-party scripts are permitted to run or which origins can read API responses. Content Security Policy and CORS have different roles. Using one header does not establish the other protections.
Our CSP rollout guide explains a complementary control. Review third-party content deliberately instead of expecting referrer restrictions to prevent all information available to scripts executing on your page.
Authorization and safe URL design remain necessary too. A private page should not become accessible merely because a browser omits the referring address.
Monitor changes and document limitations
Review the policy when adding embedded services, outbound integrations, or new URL parameters. A setting selected before an account feature existed may no longer describe the data being disclosed.
Keep safe test cases in regression checks where practical. Test the effective browser result after infrastructure changes that can alter response headers. A deployment that succeeds mechanically can still change privacy behavior.
State the limits clearly to stakeholders. The policy reduces a specific disclosure channel, while application data handling, logs, browser extensions, and authorized scripts require their own assessment.
A practical verification scenario
Consider a support page whose URL contains a synthetic ticket identifier and that loads an external image. The review should identify whether the image request receives a full referring URL, only an origin, or no referrer under the selected policy. Repeat the observation for a same-origin image and an outbound link so the result is not generalized from one request type.
Then remove the identifier from the test URL and compare what remains. This demonstrates why URL minimization and referrer policy are complementary rather than competing fixes. Document which information the destination legitimately needs and whether another integration depends on a different behavior.
Keep the test page and receiving endpoint under approved control. Do not use a real customer ticket or a third-party collection service to prove the point. Retain a safe request summary, the effective policy, browser context, and the expected outcome as a repeatable deployment check.
Frequently asked questions
Does no-referrer remove sensitive data from browser history?
No. It controls supported referrer transmission. History, logs, copied links, and other storage or sharing paths are separate concerns.
Is an origin the same as the complete page URL?
No. It omits the path and query while identifying scheme, host, and port. Choose the amount of information the destination legitimately needs.
What should I verify after deployment?
Inspect the effective policy and actual requests in representative browsers. Confirm both privacy expectations and legitimate navigation or integration behavior using non-sensitive test values.
