Outbound jumps may send referrer data; sensitive cases must disclose or block

What it is

Browsers by default tell the destination “which page I came from,” in the Referer header or whatever the later referrer policy allows. That source URL may hold a medical-record id, a password-reset token, an unpublished draft path, an intranet hostname. Outbound jumps carry the source: the destination, CDNs along the way, sometimes their analytics scripts, see the sensitive address the person was just on. Privacy-sensitive products either cut that carry or say before the jump what will be sent. Painting the link as an ordinary outbound is not enough.

Why it happens

Referrer exists so the destination can log and hotlink-protect. It also leaks the path. Referrer-Policy can shrink the leak to origin, to same-origin, or to nothing. rel="noreferrer" also drops window.opener, so the new page cannot operate the original document through opener. Default policy has changed across browser versions; a product that declares nothing exposes the current browser default—and the user cannot see the header.

What leaks is not “visited this brand” but the concrete coordinate of this page. An unsubscribe link in mail, a shared preview that still has a token, a back-office /patients/18/notes treated as an ordinary outbound into a third-party support widget, and the third party has that path. In a sensitive case, “disclose” means whether the path will be sent, not “this is an external website.” Blocking is the harder layer: outbound links on sensitive pages default to no-referrer, or rewrite through a strip-the-header redirect. If the redirector itself leaks, the block failed.

Studying it

From a page whose path is sensitive, click an outbound link and read Referer at the destination (or a test sink). Compare default, strict-origin-when-cross-origin, no-referrer, and whether the jump is disclosed beforehand.

• Dependent variables: whether the destination received the full path, whether people knew the current address would be sent, whether a sensitive token appeared in the referrer.
• Independent variables: policy, new window or not, whether an in-site redirector was used.
• Methodological note: HTTPS-to-HTTPS defaults are tighter than they used to be. A lab that only scores “the brand origin was seen” will understate path leakage and overstate “already safe.” Use paths that contain identifiers as the stimulus. Do not fold cross-site cookies and referrer into one privacy score.

Where it stops holding

Public marketing and documentation sites often owe the destination referrer as analytics; cutting it breaks their attribution and is not a sensitive case. A URL the user copied from the address bar and shared is outside referrer policy. In-site jumps are not outbound carry. Some analytics scripts wrap outbound clicks themselves; the product’s noreferrer does not cover requests those scripts fire—that is a separate switch in the script config.

Applying it

• On pages whose URLs contain identifiers, set Referrer-Policy: no-referrer or at least strict-origin-when-cross-origin. Add rel="noreferrer noopener" on outbound links from sensitive pages.
• Back office, medical records, and tokenized mail landings should send outbound clicks through a header-stripping redirect, or say before the jump “the other site will know you came from this page.”
• Audit outbound jumps beyond href, including those launched by third-party widgets.
• Verify: from a URL that contains an internal id, click outbound and inspect the header at the sink. A full path is a failure. Open a noopener new window from that page; the opposite side must not read this document. A public blog may keep the default; do not share one globally loose policy with the medical-record page.

Related

• Within the group: G4.08.1 External links must look different from in-site links so the jump can be predicted · G4.08.2 Leaving with unsaved changes must intercept, not silently discard · G4.08.3 Jumping to another domain is a trust transfer; high-risk cases need a second confirm · G4.08.4 Leave prompts only where data would actually be lost; overuse numbs people
• Adjacent: G4.04 New window versus in-place navigation · O1.02 Data minimization · O3.17 On-screen exposure of sensitive information
• Search terms: referrer leakage · noreferrer · Referrer-Policy