What does an external link reveal? Referrer policy, paths and query strings

Draw two addresses before choosing a policy

In the example, a visitor starts on a support page and follows a link to a manual on another site. Put the source address and destination address in separate columns in your notes. Mark which team controls each one. This simple exercise prevents a discussion about referral reporting from accidentally becoming a discussion about the link’s own campaign parameters.

The MDN Referer reference explains that this request header can identify a referring address, with information such as its origin, path and query. It excludes the fragment and username/password information. A fragment beginning with a hash is therefore different from a query beginning with a question mark in this particular header. That distinction does not make fragments a general safe place for secrets.

Use descriptive fictional values such as case-example rather than an actual customer number. Ask the reviewer to identify the two addresses in a network record before drawing a conclusion. If they cannot point to which is the request destination and which is the referral field, the evidence is not yet specific enough.

Choose a disclosure level for a reader journey

According to the current MDN Referrer-Policy reference, modern default behavior is strict-origin-when-cross-origin: same-origin requests can include the source path and query, cross-origin requests normally disclose the origin, and secure-to-insecure downgrades omit the referrer. No-referrer omits it; same-origin restricts it to that origin; strict-origin sends an origin where allowed without the source path. These are policy rules, not evidence of what a particular request actually sent.

Start with a written need. A public resource directory might want other publishers to recognize its referring origin. A recovery journey may have no such requirement. A private application should not accept a broad policy merely because a public marketing page uses it. Record the owner who can explain the choice and the journeys that must keep functioning after a change.

The W3C policy definitions distinguish full referring addresses, origins and omitted referral information. The older recommendation contains a historic default; the current browser reference above is the basis for the modern default described here. Use named policies in a review rather than copying an old article’s claim about what browsers always do.

Do not mistake missing referral data for anonymity

Suppose the portal deliberately links to a manual address containing a customer identifier. Removing the referral header leaves that destination identifier in the request you asked the visitor to make. The review must therefore include the constructed link itself, not simply whether the browser reports a referring page. The same separation applies to a copied URL sent in a message.

For this reason, keep the policy review alongside an inventory of the data your links intentionally carry. Challenge identifiers that are unnecessary to the destination’s job. Ask why a stable customer key is needed when a generic support landing page would answer the question. This is a design decision for your application, not a claim that every URL parameter is inappropriate.

Likewise, a blank referral field is not a complete account of a third party’s data collection. Treat the narrow test as narrow evidence. If the project needs a wider privacy assessment, list that separately instead of renaming a successful header check as an anonymity guarantee.

Handle integrations with an explicit acceptance test

A policy change may intersect with a workflow someone already depends on. Ask its owner what visible outcome matters: the manual opens, an embedded help service loads, or origin attribution appears where legitimately expected. Do not weaken the policy preemptively for an unspecified future integration. Equally, do not call the rollout finished while a documented dependency is untested.

Capture a before-and-after example for each chosen journey. Record any browser privacy settings that differ from your normal test profile. A discrepancy needs explanation; it is not a reason to keep toggling settings until one screenshot resembles a desired result. Keep the result with the configuration change so another maintainer can repeat the focused check.

Keep the review small enough to repeat

Finish with a short register: page class, chosen policy, responsible layer, tested destination and next review trigger. A new recovery flow or external help integration is a sensible trigger. Revisit the destination parameters at the same time, since those may change independently of headers.

For adjacent issues, use our guide to Sponsored, ugc and nofollow links: qualify the relationship accurately, the explanation of Password reset and magic links fail: trace the request, email and final action, and the review of Use access logs and error logs to investigate a website failure. Keep those checks distinct from this one: the useful outcome here is an intentional, observable boundary for referring-address information, with no claim that the rest of the site’s privacy work has disappeared.