Referrer-Policy Limits URL Data Sent Across Requests
A URL can contain more information than a destination needs. Paths and query strings may expose document identifiers, search terms, workflow state, or other context. When a browser follows a link or fetches a resource, referrer handling determines how much of the source URL can accompany that request in the HTTP Referer header.
Referrer-Policy gives the response an explicit rule for that disclosure. It does not encrypt URLs or remove data already sent elsewhere. Its role is narrower: constrain referrer information emitted by the browser for subsequent requests.
The policy controls disclosure granularity
A response can set:
Referrer-Policy: strict-origin-when-cross-originThis policy sends the full referrer URL for same-origin requests, sends only the origin for cross-origin requests when the security level does not decrease, and omits the referrer on a downgrade such as HTTPS to HTTP.
For a page at:
https://app.example/account/orders/482?view=detaila same-origin request may carry the fuller source URL, while a request to another HTTPS origin is limited to:
Referer: https://app.example/The destination still sees which origin initiated the request, but not the source path and query.
Cross-origin disclosure deserves deliberate limits
Referrer data is often operationally useful. Analytics, abuse detection, and traffic attribution may depend on it. Sending the complete URL to every external destination, however, can disclose details that have no role in serving the request.
A page can load images, fonts, scripts, analytics endpoints, support widgets, and outbound links from several origins. Each cross-origin request is a potential disclosure boundary.
A policy that reduces cross-origin referrers to the origin keeps coarse attribution while limiting path-level detail. Applications that require stronger privacy can choose a policy that sends less.
The correct setting depends on actual data flows, not on maximizing or eliminating the header in every case.
no-referrer removes the header
The strictest simple choice is:
Referrer-Policy: no-referrerThe browser omits referrer information from requests covered by the policy.
This can fit pages where even the source origin should not be disclosed. It can also break systems that legitimately depend on referrer data for analytics or navigation context, so the change needs application testing.
Referrer information should not be treated as an authentication factor. A missing or forged Referer header must not become a security bypass. Server authorization still needs credentials and policy checks designed for that purpose.
same-origin keeps detail inside one origin
Another useful policy is:
Referrer-Policy: same-originSame-origin requests can receive referrer information, while cross-origin requests receive none.
This creates a clear disclosure boundary at the origin. It can suit applications that use detailed referrer context internally but have no reason to reveal even their origin to external destinations through this header.
The trade-off is reduced cross-origin attribution. External services that expect a referrer may see no source information.
origin removes path and query detail
The origin policy sends only scheme, host, and port information:
Referrer-Policy: originFor a source such as:
https://portal.example/private/report?id=739the referrer becomes:
https://portal.example/This is useful when origin-level attribution is enough. It prevents the destination from receiving the source path and query through the referrer mechanism.
It does not make sensitive data in URLs safe. URLs can appear in browser history, logs, screenshots, copied links, monitoring systems, and other channels. Secrets and durable credentials should not be placed in URLs merely because referrer disclosure has been reduced.
Downgrade behavior is a separate dimension
Policies with strict- in their name account for transport downgrade. A request from HTTPS to HTTP crosses from an authenticated, encrypted transport to an insecure one.
For example, strict-origin sends an origin referrer when the security level is maintained and omits it on a downgrade. strict-origin-when-cross-origin combines that downgrade rule with fuller same-origin disclosure.
This distinction matters on sites that still link to or load legacy HTTP destinations. A policy can avoid forwarding referrer information into the downgraded request even when it permits referrers in other cases.
Transport security and referrer policy remain separate controls. Omitting a referrer does not make an HTTP request confidential.
Per-element policy can narrow individual requests
HTML also provides referrer controls on selected elements. For example:
<a href="https://external.example/" referrerpolicy="no-referrer">
External documentation
</a>A specific element can therefore use a policy suited to that destination.
Per-element settings are useful for exceptional flows, but a response-level Referrer-Policy establishes the baseline. Relying on developers to annotate every external link or resource individually creates room for omissions as templates change.
A practical design sets a safe response default and uses narrower exceptions only where a documented integration needs them.
Query strings require independent discipline
Referrer policy reduces one path by which URL data can leave a page. It does not justify putting access tokens, password-reset secrets, session identifiers, or personal data into query strings.
A sensitive query can still be stored by servers, reverse proxies, browser history, observability systems, or copied URLs. It may also reach application code and third-party scripts running in the page.
When a workflow must use a URL-carried one-time token, the application should minimize its lifetime and exposure, consume it promptly, and avoid propagating it into later URLs. Referrer policy is defense in depth around that design, not the primary secret-storage mechanism.
Redirects and embedded resources need testing
Real navigation chains are rarely a single request. A link may redirect through several origins before reaching its final destination. A page may also fetch resources from origins that are not obvious from the visible interface.
Testing should cover redirects, external links, images, scripts, stylesheets, iframes, form flows, and client-side navigation. Browser developer tools can show the actual request headers produced by the deployed policy.
Server-side tests that only check whether the response header exists cannot confirm every browser request path. The useful assertion is behavioral: the destination receives no more referrer information than the selected policy permits.
Policy should be consistent across sensitive routes
A strict policy on an account page can be weakened if a navigation first lands on another same-site route that serves a more permissive policy before contacting an external origin.
Applications should map policy to document sensitivity and navigation behavior. Shared middleware can provide a consistent baseline, while route-specific overrides remain explicit and reviewed.
Error pages deserve the same attention. They can include request paths or diagnostic context and may load external resources just like successful pages.
The boundary is information carried by the browser
Referrer-Policy is valuable because it controls a specific browser disclosure channel. It can preserve full same-origin context, reduce cross-origin data to an origin, or suppress referrer information entirely.
The header does not sanitize URLs, authorize requests, protect HTTP transport, or erase data from logs. Those properties belong to other controls.
A sound deployment starts with the minimum referrer detail integrations actually require, keeps sensitive values out of URLs where possible, and tests real navigation and resource flows. The result is a smaller disclosure surface without assigning the header responsibilities it does not have.