Referrer-Policy Reduces Referrer Data on Outbound Requests

A browser can attach a Referer request header when a document navigates to another page or fetches a subresource. Without a suitable policy, that header can expose more of the source URL than the destination needs. Paths can contain internal object names, routing details, campaign parameters, or other context that should not cross a trust boundary.

Referrer-Policy gives a site control over that disclosure. The policy determines which referrer information the browser may attach to eligible requests. It does not authenticate the destination, encrypt traffic, or replace URL design discipline. Its role is narrower: reduce the source URL data released by the browser.

Origin-only policies remove path detail

An origin consists of the URL scheme, host, and port. A policy that sends only the origin strips the path, query string, and fragment-related context from the referrer value.

For example, a page at:

https://portal.example/account/invoices?view=recent

can initiate a request whose referrer is reduced to:

https://portal.example/

under an origin-only policy when a referrer is sent.

That reduction matters because URL paths and queries often accumulate application context. Even when none of that data is a credential, disclosing it to an unrelated destination can reveal information that has no purpose in the receiving request.

The response header can set a document policy

A server can declare a policy in an HTTP response:

Referrer-Policy: strict-origin-when-cross-origin

strict-origin-when-cross-origin keeps more detail for same-origin requests, sends only the origin for cross-origin HTTPS requests, and omits the referrer on a downgrade from HTTPS to HTTP.

The distinction between same-origin and cross-origin traffic is useful for applications that rely on local request context while limiting data sent to other origins. It also keeps downgrade behavior conservative, since an HTTPS URL should not be exposed through a referrer on an insecure HTTP request.

no-referrer removes the header’s referrer value

A stricter deployment can use:

Referrer-Policy: no-referrer

With no-referrer, the browser does not send referrer information for requests governed by that policy. This can be appropriate for pages where source-location disclosure has little operational value.

The tradeoff is functional rather than cryptographic. Analytics, diagnostics, anti-abuse systems, or application logic may use referrer data as one input. Removing it can reduce that signal. Such systems should not treat the Referer header as trustworthy proof of identity or authorization in the first place, because request metadata is not an authentication credential.

same-origin confines referrer data to the origin

The same-origin policy sends referrer information for same-origin requests and omits it for cross-origin requests:

Referrer-Policy: same-origin

This creates a clear boundary for applications that want internal navigation context but do not want referrer data leaving the origin. It can be a useful fit for administrative interfaces, account areas, or applications with external links that do not need source context.

The boundary is origin-based, not organization-based. Two subdomains such as app.example.com and docs.example.com are different origins even if the same operator controls both.

Policy can also be attached to individual elements

HTML supports a referrerpolicy attribute on several elements that initiate requests. A link can therefore use a policy narrower than the document default:

<a href="https://external.example/report"
   referrerpolicy="no-referrer">
  External report
</a>

An image can carry its own policy as well:

<img src="https://cdn.example/image.png"
     referrerpolicy="no-referrer"
     alt="Diagram">

Element-level policy is useful when one request has a distinct disclosure boundary. A document-wide header remains easier to audit as the baseline because it covers requests without requiring every template author to remember a local attribute.

Redirects make the final disclosure path less obvious

Outbound navigation may pass through redirects before reaching its final destination. Referrer processing follows browser rules across those transitions, and a policy should be chosen with the full request path in mind rather than only the first URL visible in markup.

This is especially relevant for link trackers, identity flows, and external services that redirect again. A restrictive source policy limits what the browser starts with, reducing the amount of source URL data available to later requests.

Redirect behavior does not make referrer policy a substitute for keeping secrets out of URLs. Sensitive tokens in query strings can surface through logs, browser history, screenshots, copied links, and other channels independent of the Referer header.

URL design remains a separate security control

A policy reduces one disclosure mechanism. It cannot make a sensitive URL safe.

Session identifiers, password-reset credentials, API keys, and comparable secrets should not be placed in ordinary URLs merely because a restrictive referrer policy is present. The policy can be changed, omitted on another route, affected by embedding context, or bypassed by disclosure channels unrelated to referrer handling.

A safer design minimizes sensitive material in URLs and then uses Referrer-Policy as defense in depth. The two controls address different failure modes.

Test the effective browser behavior

A configured header is only useful if it reaches the intended responses with the intended value. Reverse proxies, application frameworks, static hosting rules, and route-specific middleware can produce different headers across a site.

Testing should cover representative same-origin requests, cross-origin requests, HTTPS-to-HTTP downgrade cases if such destinations exist, redirects, and any element-level overrides. Browser developer tools or a controlled receiving endpoint can show the Referer value that actually arrives.

The target state is a deliberate disclosure boundary: enough referrer context for legitimate application needs, but no more source URL detail than the destination requires.