Wiki · Concept · Last reviewed June 25, 2026

Referrer Policy

Referrer Policy is a W3C browser privacy mechanism for controlling how much referrer information a page sends when it loads subresources or sends a user, iframe, or agent to another URL.

Category: Concept Updated: June 25, 2026 Tags: browser privacy, Referer, agents, web governance

Definition

Referrer Policy is defined in the W3C Candidate Recommendation dated January 26, 2017. 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 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, 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, or dashboard routes that a human did not deliberately choose one link at a time.

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, and link, 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, or render a generated report that includes external resources. 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, and whether the request was caused by a user action, page script, 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.

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 and the WHATWG Fetch Standard. 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.

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