# Referrer-Policy (/en/docs/web-security/security-headers/referrer-policy)



Every time a user follows a link, and every time a page loads a cross-origin
resource (an image, a script, an iframe, an analytics beacon), the browser
tells the destination which page the request came from in the `Referer`
header (a historical misspelling of "referrer" that stuck). That address can
include the origin, the path, and the query string of the current page, so
whatever lives in your URLs travels with it: password-reset and other
capability links, search queries, personal data in paths. It goes to
analytics providers, CDNs, ad networks, and every site you link to.

`Referrer-Policy` is the response header that controls how much of that URL
goes out, from the full address down to nothing at all. This is the value to
ship on every HTML response (see the [recommendation](#recommendation)):

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

## Values and what each does [#values-and-what-each-does]

In the table, "full URL" means origin plus path plus query string; the
browser never sends the fragment (`#...`) or embedded credentials under any
policy. "Downgrade" means a request from an HTTPS page to a plain HTTP
destination.

| Value                             | Status  | What is sent                                                            |
| --------------------------------- | ------- | ----------------------------------------------------------------------- |
| `no-referrer`                     | ✅ Good  | Nothing, on any request.                                                |
| `no-referrer-when-downgrade`      | ❌ Risky | Full URL everywhere, nothing on downgrade. The pre-2020 legacy default. |
| `origin`                          | ✅ Good  | Origin only, everywhere, even on downgrade.                             |
| `origin-when-cross-origin`        | ✅ Good  | Full URL same-origin, origin cross-origin and on downgrade.             |
| `same-origin`                     | ✅ Good  | Full URL same-origin, nothing cross-origin.                             |
| `strict-origin`                   | ✅ Good  | Origin only, nothing on downgrade.                                      |
| `strict-origin-when-cross-origin` | ✅ Good  | Full URL same-origin, origin cross-origin, nothing on downgrade.        |
| `unsafe-url`                      | ❌ Risky | Full URL everywhere, including on downgrade.                            |

The names read systematically: a `strict-` prefix means nothing is sent on a
downgrade, and a `-when-cross-origin` suffix means the full URL stays on
same-origin requests while less goes out cross-origin.

When a page sends no policy, every current engine defaults to
`strict-origin-when-cross-origin`; Chrome, Firefox, and Safari all adopted
this default in recent years. Before that change the default was
`no-referrer-when-downgrade`, which sends the full URL to every cross-origin
destination.

The header is not the only delivery form. A `<meta name="referrer"
content="...">` tag does the same job in markup, a `referrerpolicy` attribute
on `a`, `area`, `img`, `iframe`, `script`, and `link` elements sets a policy
for one element, and `rel="noreferrer"` on a link omits the `Referer` header
entirely (it also implies `noopener`).

## What it protects against [#what-it-protects-against]

* **URL secrets leaking to third parties.** Capability URLs (password-reset
  links, invite links, signed URLs), search queries, and personal data in
  paths otherwise arrive at every analytics script, CDN, ad tag, and linked
  site. A strict policy strips the path and query before the request leaves
  the browser.
* **Cross-site tracking granularity.** A full referrer tells a third party
  exactly which page the user was on, not just which site. Sending the origin
  only is data minimization; both Mozilla and Chrome framed the default
  change as a privacy improvement.

It is not a CSRF defense. The `Referer` header is too unreliable to build
request-forgery protection on; use CSRF tokens and check the `Origin` or
`Sec-Fetch-Site` headers server-side instead, as
[web.dev's referrer best practices](https://web.dev/articles/referrer-best-practices)
spell out.

## Risks without it [#risks-without-it]

Omitting the header is no longer the leak it used to be, because the current
browser default is already `strict-origin-when-cross-origin`. Set it
explicitly anyway. Defaults vary across browser versions and change over time
(the current one only arrived between 2020 and 2021), an older browser still
applies `no-referrer-when-downgrade` and sends the full URL to every
cross-origin destination, and a single lax value in a stray meta tag or
element attribute silently reintroduces the leak. An explicit header states
the policy you chose instead of inheriting whatever the browser ships.

## Risks and gotchas when using it [#risks-and-gotchas-when-using-it]

* **Analytics lose page-level detail.** With origin-only values, the sites
  you link to (and their analytics) see `https://example.com/` instead of the
  full page path. Domain-level source attribution keeps working.
* **You cannot loosen it everywhere.** Safari caps all cross-site referrers
  at the origin regardless of your policy (Intelligent Tracking Prevention),
  and Firefox (with Tracking Protection) ignores the lax
  values (`unsafe-url`, `no-referrer-when-downgrade`,
  `origin-when-cross-origin`) on cross-site requests. `unsafe-url` cannot
  restore full cross-site referrers outside Chromium.
* **Element attributes win.** A `referrerpolicy` attribute on a link, image,
  script, or iframe overrides the page policy for that element, in either
  direction.
* **Fallback syntax works in the header only.** `Referrer-Policy:
  no-referrer, strict-origin-when-cross-origin` is valid; browsers skip
  unknown values and the last recognized one wins. The comma syntax does not
  work in the `referrerpolicy` attribute.
* **`no-referrer` can break Referer-based checks.** Some payment and
  fraud-detection flows and hotlink checks require a `Referer`; going fully
  silent site-wide can break them.

## How to set it up [#how-to-set-it-up]

1. Set `Referrer-Policy: strict-origin-when-cross-origin` on all HTML
   responses. The policy applies to the document that received it, so cover
   every page, not just the home page.

2. For individually sensitive outbound links, cut the referrer at the
   element level:

   ```html
   <a href="https://example.net/partner-portal" rel="noreferrer">Partner portal</a>
   ```

3. Check the deployed header, and the rest of your response headers, with
   the [security headers scanner](/tools/security-headers).

## Recommendation [#recommendation]

Send `Referrer-Policy: strict-origin-when-cross-origin` on every HTML
response:

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

This is the value the
[OWASP HTTP Headers cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)
recommends: the full URL stays within your own site, cross-origin
destinations get the origin only, and nothing is sent on a downgrade. It
matches the current browser default, but set it explicitly rather than
relying on defaults. If your URLs carry secrets even for same-origin
navigation (reset tokens, signed URLs), step up to `no-referrer` and accept
that Referer-based checks stop working.

## Browser support [#browser-support]

Baseline widely available: the header is supported in every current browser,
so support is effectively universal, and all current engines default to
`strict-origin-when-cross-origin` when no policy is set. Browsers can also be
stricter than your policy: Safari caps cross-site referrers at the origin
regardless (Intelligent Tracking Prevention), and Firefox ignores the lax
values on cross-site requests with Tracking Protection.

## FAQ [#faq]

### What is strict-origin-when-cross-origin? [#what-is-strict-origin-when-cross-origin]

It is the default policy in every current browser. On same-origin requests it
sends the full URL, meaning origin, path, and query. On cross-origin requests
it sends only your origin. On a downgrade from HTTPS to HTTP it sends nothing.
It keeps paths and queries off other sites while preserving domain-level
attribution.

### Does Referrer-Policy break Google Analytics? [#does-referrer-policy-break-google-analytics]

No. A stricter policy reduces referrer granularity, so a destination site and
your inbound reports see your origin rather than the full path, but
domain-level source attribution keeps working. Analytics that group traffic by
referring domain are unaffected; only the path-level referrer detail is trimmed
on cross-origin requests.

### What is the difference between referer and referrer? [#what-is-the-difference-between-referer-and-referrer]

`Referer` is the request header the browser attaches, and its name is a
historical misspelling that stuck in the HTTP standard. `Referrer-Policy`, the
response header that controls it, and `document.referrer`, the JavaScript
property that exposes it, are both spelled correctly. Same concept, one word
misspelled for compatibility.

## See also [#see-also]

* [Security headers overview](/en/docs/web-security/security-headers)
* [The removed CSP referrer directive](/en/docs/web-security/policies/content-security-policy/directives/referrer),
  which this header replaced
* [Strict-Transport-Security](/en/docs/web-security/security-headers/strict-transport-security),
  which removes the plain-HTTP hops the `strict-` values guard against
* [Security headers scanner](/tools/security-headers) to check your
  deployed headers

## Sources [#sources]

* [W3C, Referrer Policy editor's draft](https://w3c.github.io/webappsec-referrer-policy/)
* [MDN, Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy)
* [MDN, Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referer)
* [web.dev, Referer and Referrer-Policy best practices](https://web.dev/articles/referrer-best-practices)
* [OWASP, HTTP Headers cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)
* [Chrome, a new default Referrer-Policy](https://developer.chrome.com/blog/referrer-policy-new-chrome-default)
* [Mozilla, Firefox referrer tracking protections](https://blog.mozilla.org/security/2021/10/05/firefox-93-features-an-improved-smartblock-and-new-referrer-tracking-protections/)