Referrer-Policy for privacy-consistent navigation

When a navigation unexpectedly exposes a path, the reliable question is not “does the browser hide referrers?” It is which policy, request direction, and redirect hop produced the actual Referer header. The answer is deterministic enough to test: same-origin requests can retain the full URL, cross-origin requests commonly retain only the origin, and a downgrade from HTTPS to HTTP sends no referrer under the modern default. BotBrowser can repeat an authorized profile and navigation fixture, but it cannot override a browser policy or prove what a remote server stores.

TL;DR

• Referrer-Policy controls the referrer value sent with requests; the wire header is spelled Referer.
• strict-origin-when-cross-origin is the modern default in browsers: full URL same-origin, origin-only cross-origin, and no value on HTTPS-to-HTTP downgrade.
• A redirect creates a new request; inspect each hop instead of assuming the first URL survives.
• Use no-referrer or a narrower policy when path/query data would be sensitive, and verify the resulting header in a controlled endpoint.
• BotBrowser repeats declared browser/profile conditions; it does not grant exceptions, inspect another origin's logs, or guarantee server retention.

Contents

• Policy and wire header
• A controlled navigation fixture
• Origin changes, downgrades, and redirects
• Evidence and decision matrix
• Conclusion
• FAQ

Policy and wire header

The Referrer-Policy response header and the equivalent HTML referrerpolicy attribute tell the user agent how much of the source URL may be sent when a request is made. The request header is historically named Referer (one “r” after the first syllable). A policy is not an instruction to a destination server and is not a data-deletion promise; it controls what the browser puts on that request.

The useful comparison is between policy values. no-referrer sends nothing. same-origin sends a referrer only to the same origin. origin sends only scheme, host, and port. strict-origin sends the origin across equal-or-more-secure transitions but suppresses it on a downgrade. strict-origin-when-cross-origin keeps the full URL same-origin, reduces it to the origin cross-origin, and suppresses it on HTTPS-to-HTTP. unsafe-url can send the full URL and should not be used when paths or query strings contain sensitive data.

A controlled navigation fixture

Use two HTTPS origins and one HTTP endpoint you own. Set the policy on the source response, navigate with a normal link, follow a server redirect, and record request headers at each endpoint. Keep URLs synthetic: never place tokens, account identifiers, or private query values in the fixture.

// Playwright-style observation, with an endpoint that echoes request headers.
const seen = [];
page.on('request', request => {
  if (request.url().includes('/referrer-observation')) {
    seen.push({ url: request.url(), referer: request.headers().referer ?? null });
  }
});
await page.goto('https://source.example.test/start');
await page.getByRole('link', { name: 'cross-origin' }).click();
console.log(seen);

Expected results under strict-origin-when-cross-origin: a same-origin request may contain the full source URL; a cross-origin HTTPS request contains https://source.example.test/; an HTTPS-to-HTTP request contains no Referer. The exact result still depends on the effective policy, browser version, and request type, so capture the response policy and browser version with the observation.

Origin changes, downgrades, and redirects

An origin is the tuple of scheme, host, and port. A path change alone is same-origin; changing any tuple member is cross-origin. Same-site is not the same as same-origin: two subdomains can be same-site for some cookie rules while still being cross-origin for referrer policy.

Redirects do not “forward” a header unchanged by magic. The browser evaluates the referrer for the next request using the effective policy and the redirecting URL. A cross-origin redirect can therefore reduce a full path to an origin, and a redirect from HTTPS to HTTP suppresses the referrer under strict policies. Test the final request and every intermediate response when a chain matters.

Evidence and decision matrix

Observation	Safe interpretation	Next action
Same-origin request has full path	Effective policy permits same-origin detail	Remove sensitive path/query data anyway; URLs are observable in other places
Cross-origin HTTPS request has source origin only	Origin reduction is working	Keep the policy and verify the destination does not need more context
HTTPS-to-HTTP request has no Referer	Downgrade suppression is working	Keep HTTPS, or treat HTTP as an explicit privacy boundary
Redirect hop differs from first request	Each hop was evaluated separately	Capture response policy and headers for every hop
Header is absent unexpectedly	Policy, referrer source, browser setting, or request mode may suppress it	Re-run with a minimal fixture and record all conditions

Do not infer a user's identity from a referrer. Servers, proxies, analytics systems, and browser extensions may retain other metadata, while Referrer-Policy does not erase logs already created. Use the smallest policy that meets the navigation requirement and avoid secrets in URLs regardless of policy.

BotBrowser's topic-specific capability is repeatable, authorized profile navigation across declared browser, platform, and proxy conditions, with the fixture's request evidence preserved. Its limitation is that it cannot override a browser's referrer policy, reveal another site's logs, force a redirect outcome, or certify retention and compliance.

Operational review checklist

Before changing a production policy, record the source and destination origins, schemes, redirect chain, and data in the source URL. Use synthetic hosts and repeat one variable at a time in a clean profile. Capture headers at every endpoint and retain only the policy, URL shape, referrer presence or origin, browser release, and fixture version. Do not collect cookies, authorization headers, real paths, or account identifiers.

For a site migration, deploy the policy on the HTTPS source before changing links. Check same-origin links, cross-origin analytics or payment links, and redirects from old paths. Keep destinations on HTTPS. If legacy HTTP is unavoidable, treat the empty referrer as expected and use an explicit, non-secret handoff rather than weakening the policy.

Defaults evolve, and an iframe, stylesheet, fetch, or navigation can have a different effective policy. A regression test should assert the destination's observed header and the absence of sensitive path data. If attribution is needed, use a short-lived random campaign token that is scoped and expiring; it is not an identity or retention guarantee.

BotBrowser's narrow role is repeatable authorized navigation in the declared profile with bounded observations for release review. The application owner remains responsible for policy, URL design, redirects, logging, deletion, and consent decisions.

Working with embedded documents

Top-level navigation is only one place where a referrer can appear. An embedded document can receive a policy from its own response, an iframe attribute, or the page that created the request. A stylesheet, image, script, fetch, or form submission can therefore produce a different result from a link click. Treat request type as part of the fixture and do not use one resource's result as evidence for another.

For a partner integration, assign ownership before launch. The source team owns path and query design, the destination team owns its response policy and logging, and the embedding team owns any referrerpolicy attribute. If a partner needs attribution, send a short-lived random value through an explicit application parameter rather than relying on an incidental private path.

Redirect and migration fixture

Create a chain such as https://old.example.test/account/overview to https://new.example.test/home, then to a synthetic partner endpoint. Capture the status, Location, response policy, and request Referer at every hop. The expected result is a sequence of independently calculated values, not a copied first header. Run the fixture with a direct link and a client-side navigation because their source documents and request modes can differ.

Incident response and rollback

If monitoring shows a sensitive path at a destination, stop adding links that carry it, change the URL design or policy, and test a redacted synthetic path. Review redirect responses and analytics in parallel. Removing a policy header is not a rollback because it can increase disclosure; a rollback restores the last understood policy and URL shape with a fixture proving the path is absent. Keep evidence short-lived and omit cookies, authorization headers, and customer paths.

Compatibility and support boundary

Standards define policy processing, while browsers decide when to apply it to a request. Updates can change defaults, embedded-resource behavior, and developer-tool presentation. Record the browser release and effective response header. BotBrowser supports this review by repeating the declared navigation in an authorized profile and preserving bounded observations. It cannot make an unsupported browser send a value, suppress a server log, or turn a local observation into a legal privacy certification.

Choosing a policy for a product flow

Start with the smallest disclosure that still serves the flow. A documentation site may need only the destination origin. An application can retain full detail for internal routing while reducing it at every partner boundary. Payment and support handoffs should use explicit, expiring values rather than depend on a private path being present.

no-referrer hides the source entirely. same-origin keeps internal detail while sending none externally. origin sends the site but not its route. strict-origin and strict-origin-when-cross-origin retain the security property that an HTTPS downgrade discloses nothing. Treat unsafe-url as an exceptional compatibility decision with an owner and review date.

Do not infer the effective value from a framework setting alone. A response header can establish policy before markup is parsed, while an element attribute can narrow one request. Capture the final request and the policy source that governed it. A visible single-page-app URL change is not automatically a network navigation or a new Referer event.

What the header cannot answer

An empty Referer does not mean a destination knows nothing. It can still see the request URL, method, allowed cookies, network metadata, and application body. A full referrer does not prove that a server retains or associates it with a person. Keep those questions separate from browser policy.

The policy also does not control links copied into chat, history, proxy logs, analytics beacons, or server-generated redirect records. It addresses one browser-to-destination header at request time. Pair it with URL redaction, access controls, transport security, retention limits, and user disclosure.

A repeatable release record

Record the fixture identifier, source policy, browser release, profile purpose, destination class, redirect hops, observed Referer shape, and pass or fail decision. Use a redacted example such as /article/<id> rather than a customer path. Mark unknown outcomes as unknown until a minimal reproduction separates policy, source type, browser control, request mode, and intermediary effects.

When domains change, rerun the matrix before launch. A new CDN, payment provider, help center, or redirect service is a new origin boundary even when the organization is unchanged. Keep the test page synthetic so reviewers can reproduce it without customer data.

The same discipline applies to campaign and support links. A campaign parameter is still part of a URL and may be copied, logged, bookmarked, or forwarded. Use a random value with a short lifetime, avoid account identifiers, and decide whether the destination really needs it. If the destination only needs to distinguish a navigation family, a coarse route label is safer than a complete source path. Document that choice in the release record so a later redesign does not reintroduce private detail.

For incident triage, compare a failing navigation with a minimal page that contains one link and one policy header. Check whether the source was opened from a bookmark, typed manually, or reached through another redirect, because a browser can have no referrer before the link is clicked. Check the request method and whether the destination is HTTPS. These controls separate an expected empty value from a regression in the application or redirect service.

Review the destination's own policy and logging separately. A destination may issue a policy for resources it loads later, but that response cannot change a header already sent by the browser. Server logs can also include a full request URL even when Referer is reduced. A complete review therefore includes request headers, URL design, redirect records, analytics configuration, and retention ownership. Referrer-Policy is a useful boundary, not a complete privacy program.

For support teams, provide a short explanation of the expected result rather than asking customers to disable privacy controls. “This navigation intentionally sends no referrer on HTTPS-to-HTTP” is actionable; “privacy mode broke the link” is not. Offer an HTTPS destination or an explicit support handoff that carries no secret path. Keep the fixture and policy version in the internal release note so the behavior can be reproduced after a browser update.

Customer-facing guidance should be direct: keep source and destination on HTTPS, remove account data from paths, and test the exact redirect chain before launch. A concise policy note helps support teams explain an empty header without asking anyone to weaken browser privacy settings. It also gives engineers a stable acceptance check when a CDN, partner, or browser release changes the navigation path.

For readers, the practical rule is simple: decide what the destination needs, declare that policy at the source, and verify the wire result with a safe test page. If a referrer is empty, preserve that result unless a documented product requirement justifies more context. If a path is sensitive, redesign the URL before considering a weaker policy. This keeps navigation predictable for users while giving operators evidence they can review after a release.

Conclusion

Treat referrer privacy as a request-by-request observation. Declare an effective policy, test same-origin, cross-origin, HTTPS-to-HTTP, and redirect paths with synthetic URLs, and inspect the actual Referer header. The next safe action is to remove secrets from URLs, keep navigation HTTPS, and retain only the minimum fixture evidence needed to explain a product decision.

FAQ

Is Referer a typo in the HTTP specification?

It is the historical header spelling. Referrer-Policy uses the correctly spelled word, while the request field remains Referer for compatibility.

Does origin hide the source site?

No. It hides path and query detail but still sends scheme, host, and port when the policy permits a referrer. Use no-referrer when even the origin is sensitive.

Can a redirect restore a full URL?

Not by itself. Each request is evaluated under the effective policy, and a less-private policy at a later response cannot retroactively add information to a request already sent.

Does BotBrowser change Referer headers?

It can reproduce a declared browser/profile workflow for measurement. Browser policy, page policy, network redirects, and destination logging remain the authorities for the result.

Next reading

• Same-Origin Policy and site isolation
• Cross-origin resource sharing boundaries
• Browser privacy research using public specifications

Public sources

Fixture origins used in the example include https://source.example.test/`, https://source.example.test/start', https://old.example.test/account/overview`, https://new.example.test/home`, and https://source.example.test/`、HTTPS.

• W3C Referrer Policy
• MDN Referrer-Policy
• MDN Referer
• BotBrowser advanced features