Wiki · Concept · Last reviewed June 25, 2026

Referrer Policy

Referrer Policy is a browser privacy mechanism for controlling how much source-URL information leaves a page in the HTTP Referer header when the browser loads subresources or navigates a user, iframe, preview, or agent to another URL.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser privacy, Referer, agents, web governance

Definition

Referrer Policy is defined in the W3C Referrer Policy specification. It gives authors a way to influence what a browser places in the HTTP Referer header when a document initiates outgoing requests, including subresource fetches, prefetches, and navigations. The spelling split is historical: the HTTP request header is Referer, while the policy header is spelled Referrer-Policy.

The policy is small, but it sits in a sensitive place. URLs often carry page paths, search terms, campaign identifiers, object IDs, file names, capability tokens, OAuth-like state, and other context that was never meant for the next site in the chain. In an AI-mediated web session, those URLs may also reflect tool state, prompt-derived query parameters, generated previews, private workspace routes, or dashboard views that a human did not deliberately choose one link at a time.

Current Context

As of June 25, 2026, the standards history needs careful wording. The latest published W3C Technical Report remains the January 26, 2017 Candidate Recommendation, but the W3C editor's draft was updated in March 2026 and identifies strict-origin-when-cross-origin as the default referrer policy. MDN's current HTTP header reference likewise describes strict-origin-when-cross-origin as the default if no policy is specified or if an invalid value is provided. Chrome announced the same default change for version 85 in 2020 as part of a broader move toward more privacy-preserving browser defaults.

For governance, that means a site should not rely on a remembered default from an old specification or a particular browser. Explicitly set the policy, test the effective network behavior in the browser versions under review, and record whether enterprise settings, private-browsing modes, extensions, embedded contexts, or automation runtimes change what is actually sent.

Mechanism

The W3C specification defines policy tokens including no-referrer, no-referrer-when-downgrade, same-origin, origin, strict-origin, origin-when-cross-origin, strict-origin-when-cross-origin, and unsafe-url. The tokens differ in how much of the source URL can be exposed, whether same-origin and cross-origin requests are treated differently, and whether a secure-to-insecure downgrade sends referrer information.

At one end, no-referrer suppresses the header. same-origin keeps referrer information within the same origin. origin reduces the value to the origin rather than the full path. strict-origin-when-cross-origin preserves more information for same-origin requests, sends only the origin for secure cross-origin requests, and withholds referrer information on downgrade. At the permissive end, unsafe-url can expose more of the source URL across boundaries, which is why the W3C security considerations treat it as a leakage risk for authors who do not intend that exposure.

Authors can deliver the policy through the Referrer-Policy response header, a meta name="referrer" element, a referrerpolicy attribute on elements such as a, area, img, iframe, link, and in current drafts script, or a noreferrer link relation. Policies can also be inherited, so review needs to identify the effective policy at the point where a request is made. The WHATWG Fetch Standard integrates referrer policy into request handling by deriving the request's referrer and setting the Referer header during fetch processing.

Agent Context

For AI Browsers and Computer Use, Referrer Policy is not an agent identity control. It does not prove whether a human or a model caused a request. Its value is narrower: it reduces accidental context transfer when an automated browser opens a link, renders an image, embeds a frame, expands a preview, or loads a third-party widget.

This matters because agents can generate browsing paths that are faster and less inspected than ordinary human navigation. A browser agent might search a private workspace, click into a vendor console, follow a generated citation, load a third-party image in a private report, or prerender a candidate page before the user sees it. A strict policy cannot clean a bad URL or govern a tool call, but it can keep the browser from automatically attaching more origin story than the target needs.

Governance Use

In governance review, Referrer Policy is evidence about ambient disclosure. It pairs naturally with Content Security Policy, Subresource Integrity, Permissions Policy, and Trusted Types. Those controls answer different questions: what may load, whether loaded bytes match a digest, which browser features are delegated, how DOM injection is constrained, and how much URL context leaves the current document.

A useful assessment does not merely ask whether a policy exists. It records the effective policy, delivery mechanism, source URL, target origin, request destination, redirect behavior, downgrade condition, browser default, and whether the request was caused by a user action, page script, speculative load, embed, or agent instruction. Sensitive dashboards, identity pages, model workbenches, support consoles, and upload review screens should be checked for missing policy, overly broad unsafe-url use, and inconsistent per-element overrides.

The first governance rule is still URL hygiene. Referrer Policy reduces automatic leakage, but sensitive systems should avoid placing secrets, bearer tokens, full prompts, case notes, personal identifiers, file names, or internal object IDs in URLs when those values can be carried by POST bodies, short-lived server state, or access-controlled records instead.

Limits

Referrer Policy is not consent, access control, data minimization by itself, or a substitute for not placing sensitive data in URLs. It does not stop explicit disclosure in the destination URL, request body, cookies, analytics payloads, pixels, API calls, or agent tool invocations. It also does not guarantee that every user agent will send a referrer; the W3C specification notes that user agents may let users suppress referrer headers regardless of page policy.

The 2017 Candidate Recommendation is also not a live browser compatibility report. Browser defaults, element support, and enterprise overrides should be checked in the actual browser version and deployment environment under review. Treat the standard as the vocabulary and algorithmic basis, then verify observed network behavior.

Review Record

Source Discipline

Claims about policy tokens, delivery mechanisms, and request processing should cite the W3C Referrer Policy specification, its editor's draft when current defaults matter, and the WHATWG Fetch Standard. MDN is useful for implementation-facing summaries and browser notes. Claims about a particular site should cite observed headers, HTML, browser version, network logs, and request traces rather than assuming defaults from standards text alone.

When a source names a browser default, record its date and browser scope. A Chrome default announcement is primary evidence for Chrome's rollout, not proof that every user agent, enterprise profile, private-browsing mode, extension environment, or automation stack behaves identically.

Spiralist Reading

Spiralism reads Referrer Policy as a rule about traces. Machines do not only decide; they leave residues in places no participant may notice. A good policy is not mystical protection. It is a modest refusal to let every click, embed, and automated request carry the whole story of where it came from.

Sources

Return to Wiki