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

TL;DR: Referrer-Policy: strict-origin-when-cross-origin is the current default: send the stripped source URL to the same origin, only its origin to other HTTPS origins, and nothing on a normal HTTPS-to-HTTP downgrade. Use no-referrer to suppress the header everywhere.

What is Referrer-Policy?

This response header governs referral information sent from a document on later navigations and resource requests. It does not erase a Referer already received by your server. The outgoing request field is spelled Referer.

How Referrer-Policy Works

For a source at https://app.example.com/account?view=full#profile, the default permits this illustrative same-origin request header:

Referer: https://app.example.com/account?view=full

For a request to https://partner.example.com, it permits only:

Referer: https://app.example.com/

The fragment is excluded in both cases. A normal cross-origin HTTP destination receives no Referer under this policy. The current Referrer Policy draft defines the default.

Syntax

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

A comma-separated header list uses the last recognized policy, not the first. This lets an older fallback precede the preferred policy:

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

The fallback list belongs in the HTTP header, not an HTML referrerpolicy attribute. The parsing algorithm processes each recognized token in order.

Policy Directives

For a source on HTTPS, the following compares a same-origin target, another HTTPS origin, and a normal non-trustworthy cross-origin HTTP target. “URL” means the source URL without user information or fragment.

Policy	Same origin	Other HTTPS origin	Other HTTP origin
no-referrer	Omitted	Omitted	Omitted
no-referrer-when-downgrade	URL	URL	Omitted
same-origin	URL	Omitted	Omitted
origin	Origin	Origin	Origin
strict-origin	Origin	Origin	Omitted
origin-when-cross-origin	URL	Origin	Origin
strict-origin-when-cross-origin	URL	Origin	Omitted
unsafe-url	URL	URL	URL

no-referrer-when-downgrade is an older default, not the current one. MDN defines each directive.

Common Examples

Inside an nginx server or location serving HTML:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

For Apache with mod_headers:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

Use the documented nginx or Apache directive and verify the final document response.

In an existing Express app, set a document default and override it for a sensitive route:

app.use((_req, res, next) => {
  res.set('Referrer-Policy', 'strict-origin-when-cross-origin')
  next()
})
app.get('/reset-password', (_req, res) => {
  res.set('Referrer-Policy', 'no-referrer')
  res.sendFile('reset-password.html', { root: '/srv/app/public' })
})

Create that HTML file under the fixed root. Returning the override from the document route governs its later requests; setting it on /api/reset-password alone would not change the calling document.

With Helmet installed, its standalone middleware can set the default:

const helmet = require('helmet')
app.use(helmet.referrerPolicy({ policy: 'strict-origin-when-cross-origin' }))

Helmet documents this option. Register a sensitive route’s override after it, and inspect the delivered HTML response to catch any later proxy setter.

For Caddy, this complete site block applies a default and then a path-specific override:

app.example.com {
    route {
        header Referrer-Policy strict-origin-when-cross-origin
        header /reset-password Referrer-Policy no-referrer
        reverse_proxy localhost:3000
    }
}

Caddy’s header directive accepts a matcher before the field name. The route block preserves the written order, so the path override runs after the default. If the backend also sets Referrer-Policy, choose which layer owns the final value rather than depending on conflicting settings.

Real-World Scenarios

A reset-password document containing a token in its URL can use no-referrer to avoid sending it to either same-origin or external subresources. The default still sends a path and query to same-origin destinations; origin-only cross-origin handling does not protect those internal requests.

A token placed in #fragment is excluded from Referer, but the default does not remove tokens in ?query for same-origin requests. Do not test only an external analytics request and conclude the page is protected: an internal image, stylesheet, or API request can receive the source path and query.

Removing a query parameter from a destination link also does not remove it from the source page’s URL. Policy is applied to the source URL when constructing the outgoing Referer.

Meta Tag Alternative

<meta name="referrer" content="no-referrer">

Place it early in the head, before resource loads. Processing this meta element updates the document’s policy for subsequent requests, including when the response supplied a different policy. HTML defines the update.

Getting Referrer-Policy right

Set the policy on the initiating document. Returning no-referrer on a JSON fetch response does not retroactively hide the incoming Referer or update the calling page’s document policy.

Common Patterns

For one link or image, use a single policy value:

<a href="https://partner.example.com/" referrerpolicy="no-referrer">Partner</a>
<img src="https://images.example.com/logo.png" referrerpolicy="no-referrer" alt="Logo">

External stylesheets can carry their own referrer policy for resources they load, which is useful when diagnosing a CSS-initiated request that differs from a document-initiated one.

Privacy Implications

Even unsafe-url excludes fragments and user information; it can still leak paths and queries. Policy is one control over referral disclosure, not a way to keep a sensitive URL out of history, logs, or other application code.

Analytics Considerations

Origin-only referrals preserve a source origin but remove the referring page path. Missing Referer can result from policy or direct navigation; do not assign a definite cause from absence alone. Query parameters placed on the destination URL are separate from referral information.

For example, an incoming https://blog.example.com/ identifies an origin but cannot tell you which article linked to the shop. A destination parameter such as ?campaign=launch can provide an application-defined label, although visitors can edit it. Do not interpret the missing source path as a broken tracking implementation when the chosen policy deliberately removes it.

Testing

curl -sS -D - -o /dev/null https://app.example.com/account

This checks what policy the server delivers. Test browser behavior by making same-origin and cross-origin requests from that document and inspecting their request headers in Network. Keep the test source URL non-sensitive.

A small same-origin probe makes this visible. Add this route to an existing Express app in a local test environment:

app.get('/referrer-probe', (req, res) => {
  res.json({ referer: req.get('Referer') ?? null })
})

From a served page at /test?marker=referrer-test, run:

for (const referrerPolicy of ['strict-origin-when-cross-origin', 'no-referrer']) {
  const response = await fetch('/referrer-probe', { referrerPolicy })
  console.log(referrerPolicy, await response.json())
}

The first same-origin request can include the source path and query; the second omits Referer. For a cross-origin comparison, navigate to a probe on another HTTPS origin you control, or inspect a subresource request there in Network. A cross-origin fetch probe would need CORS permission before JavaScript could read its JSON; CORS and referrer policy are separate checks.

Check the compatibility data when supporting older clients. Browser privacy settings may restrict disclosure beyond a site’s selected policy; a policy describes what may be sent, not a guarantee that every request includes it.

Related Headers

• Referer
• Origin
• Content-Security-Policy