How to Set Referrer-Policy: strict-origin-when-cross-origin

Q: Does this value send anything cross-origin at all?

Yes — the bare origin (https://app.example/) on same-security cross-origin requests, and nothing on an HTTPS to HTTP downgrade. Only the path and query are stripped cross-origin.

This page covers deploying one specific value of the Referrer-Policy header and is part of the Referrer-Policy and Permissions-Policy reference. strict-origin-when-cross-origin is the correct default for nearly every production site: it sends the full URL on same-origin requests, only the bare origin on cross-origin requests, and nothing at all when the destination downgrades from HTTPS to HTTP. That combination keeps internal navigation attribution intact while preventing paths, query strings, tokens, and PII from leaking to third parties.

Configuration Syntax & Exact Values

The complete header value is a single token:

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

Annotated behaviour of that one token:

Same-origin request (https://app.example → https://app.example/x?y=1) — sends the full URL including path and query. Internal analytics and navigation tracking keep working.
Cross-origin, same security level (https://app.example → https://other.example) — sends origin only (https://app.example/). Path and query are stripped before the request leaves the browser.
Downgrade (https://app.example → http://other.example) — sends an empty Referer. Nothing leaks over the insecure hop.

There are no parameters, no quotes inside the value, and no list. A misspelled token (e.g. strict-origin-when-crossorigin) is not an error — the browser silently falls back to its own default, so the exact string matters.

Server-Side Configuration

Nginx

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

always emits the header on error responses (4xx/5xx) too. Any add_header inside a location block discards inherited ones, so repeat this line in every block that sets its own headers.

Apache

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

always covers internally generated error responses; set overrides any value emitted by an upstream module. Requires mod_headers.

Cloudflare

Rules → Transform Rules → Modify Response Header → Set header Referrer-Policy to strict-origin-when-cross-origin, matching All incoming requests. A Transform Rule overwrites rather than appends, so it will not produce a duplicate alongside an origin value.

Node/Helmet

const helmet = require("helmet");

app.use(
  helmet({
    referrerPolicy: { policy: "strict-origin-when-cross-origin" },
  })
);

Helmet normalises header casing and prevents a duplicate Referrer-Policy. Register it before your route handlers so it applies to every response.

The same origin URL leaks its full path internally, only its origin to a cross-origin HTTPS target, and nothing on an insecure downgrade.

Diagnostic & Verification Steps

Confirm the header value:

curl -sI https://app.example | grep -i referrer-policy

Expected output:

referrer-policy: strict-origin-when-cross-origin

Open DevTools → Network → enable Preserve log. Click an internal link and inspect the new request’s Request Headers. Expected Referer:
```
Referer: https://app.example/dashboard?tab=billing
```
Click an external HTTPS link and inspect its Request Headers. Expected truncated Referer:
```
Referer: https://app.example/
```
The path /dashboard and query ?tab=billing are gone — this is the cross-origin truncation that proves the policy is live.
Read document.referrer in a third-party page’s console after navigating from your site. Expect https://app.example/, never a path.

Edge Cases, Security Implications & Safe Rollback

Analytics attribution by full URL. Tools that key on the full referring URL lose path detail cross-origin. The origin is still sent, so origin-level attribution survives; move finer attribution to first-party query parameters (e.g. UTM tags on your own links) or server-side logging rather than weakening the policy.
OAuth and redirect flows that read the referrer. Some identity providers or webhook endpoints inspect Referer to validate the calling origin. Under this policy they receive your origin (e.g. https://app.example/) cross-origin, which is sufficient for origin checks. Flows that require the full callback path in Referer are broken by design and must carry that data in the state parameter or redirect URI instead — never rely on Referer for OAuth security.
<meta name="referrer"> override. A <meta name="referrer" content="..."> in the page can override a missing or malformed HTTP header. Remove conflicting meta tags so the server header is authoritative.
Legacy agents. IE11 and Safari before 12.1 ignore this token and fall back to no-referrer-when-downgrade. If strict legacy parity is mandatory, document the gap; do not switch the whole site to the weaker value to satisfy obsolete browsers.

Safe rollback (non-destructive). This header has no client-side lock-in, so reverting is immediate:

Replace the value with the broadest compatible fallback:

Header always set Referrer-Policy "no-referrer-when-downgrade"

Purge CDN/edge cache.
Re-verify: curl -sI https://app.example | grep -i referrer-policy.
Confirm the dependent flow (analytics or OAuth) recovers, then plan a server-side fix so you can return to strict-origin-when-cross-origin.

Frequently Asked Questions

Is strict-origin-when-cross-origin already the browser default? Modern Chromium, Firefox, and Safari default to it, but defaults are not contractual and privacy-hardened or legacy agents differ. Set the header explicitly for deterministic, auditable behaviour.

Does this value send anything cross-origin at all? Yes — the bare origin (https://app.example/) on same-security cross-origin requests, and nothing on an HTTPS→HTTP downgrade. Only the path and query are stripped cross-origin.

Will it break OAuth logins? No, provided the flow validates origin (which still arrives in Referer) and carries state in the state/redirect parameters rather than depending on the full referring path. Relying on the full Referer path for OAuth is itself insecure.

Conclusion

Roll this out incrementally: set strict-origin-when-cross-origin in staging, confirm the cross-origin Referer truncation in DevTools and that analytics and any redirect flows still behave, then promote to production at a single enforcement layer (edge or origin, not both). Because the header carries no client-side persistence, rollback is just a value change plus a cache purge.

Referrer-Policy and Permissions-Policy — the parent reference covering all policy values and Permissions-Policy.
Permissions-Policy: disabling browser features — the companion capability-control header.
Web Security Headers Fundamentals — the full set of hardening headers.