What Is Referrer-Policy?

At a glance

Referrer-Policy balances privacy, attribution and security. Policies such as strict-origin-when-cross-origin send only the origin on cross-origin requests rather than the full path.

Controlling source-URL disclosure

When a browser requests a resource from a page, the Referer header may identify the source URL. Referrer-Policy controls whether to send a full address, only its origin or nothing. This balances attribution, compatibility and privacy. The header historically spells Referer with one r in the middle; the policy uses Referrer.

Full URLs can reveal paths, query parameters and page structure. Session tokens, email addresses or internal identifiers placed in URLs may reach third parties through outgoing requests. Keep sensitive data out of URLs first; referrer controls then further limit routine disclosure.

Same-origin, cross-origin and downgrade behavior

• Strict-origin-when-cross-origin generally sends a full URL within the same origin, only scheme, host and port across origins, and no referrer on an HTTPS-to-HTTP downgrade.
• No-referrer sends none, maximizing this aspect of privacy while reducing attribution in analytics, affiliate systems and security logs.
• Same-origin sends referrers only within an origin. Origin and strict-origin send only the origin, with the strict variant also limiting security downgrades.
• Unsafe-url may send full paths across origins. Its name highlights the privacy concern; use it only for a specific, understood compatibility requirement.

Policies on responses, pages and links

A response header can establish the page default; meta tags and referrerpolicy attributes on links or iframes provide more granular controls. Browsers determine the applicable policy under the specification. Third-party code and redirects can still affect the final recipient.

Tighter policies may affect advertising, payment-return flows, affiliate attribution or hotlink checks. Identify actual Referer dependencies before changing them. Referer is not reliable authentication: it can be absent or supplied by non-browser clients.

Practical use and interpretation

An observed Referrer-Policy can be displayed and explained for same-origin, cross-origin and downgrade requests. Without an explicit header, browser defaults still apply; do not assume that a full URL is always sent.

Potential disclosure depends on sensitive URL parameters and third-party resources. A permissive policy is a clue, while concrete consequences require an identifiable data path.

Points to consider

Permissive policies may reveal more paths; restrictive ones may affect attribution. Sensitive URL parameters are an important part of the assessment.

Frequently asked questions

Can no-referrer break functionality?

It may affect attribution, affiliate measurement or hotlink controls that rely on referrers. Check those dependencies first.

Can Referer determine access permissions?

It should not replace authentication or authorization. Browser policies can omit it, and non-browser clients can forge it.

Does a missing Referrer-Policy expose the full URL?

Modern browsers have defaults. Behavior depends on the browser and request context, so absence alone does not justify an absolute claim.