# How much of your page address do you share when visitors click away?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

The referrer check looks for an explicit Referrer-Policy. Here is what browsers do without one and which value fits most sites.

The referrer check looks for an explicit Referrer-Policy on your pages. It decides how much of the page address a browser shares with the next site when a visitor follows a link.

## What does this check look at?

It looks at whether your pages set an explicit policy for how much of their address goes to other sites when a visitor follows a link. MDN says the header controls how much referrer information should be included with requests. It matters most when addresses carry things they should not, such as reset tokens or search terms.

Pulse and Deep scans both run it.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Pass | An explicit, restrictive policy is set. | Nothing. |
| Attention | No explicit restrictive policy was seen. | Set one, and keep secrets out of addresses either way. |

Browsers apply a default when it is missing, so absence does not prove full addresses leak. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.

## How serious is a finding?

Treat this as a hardening gap. It makes an attacker’s job easier but gives them no path of its own, so fix it after anything more direct. Confidence starts low, because it is inferred from headers or declarations rather than shown directly. The report lists what to fix by how directly someone could use it, not by the severity label.

### What does a confirmed finding have to show?

| Part | For this check |
| --- | --- |
| Where it starts | Content or a frame an attacker can influence |
| The protection that should stop it | A browser protection header is missing or weak |
| What is reached | How browsers treat your pages |
| What follows | A hardening gap; no exploit was shown |

## Which standards does it relate to?

| Standard | Reference |
| --- | --- |
| OWASP Top Ten | `A02:2025` Security Misconfiguration |
| CWE | `CWE-200` |
| ASVS | `v5.0.0-3.4.5` |

Each one is a related control, not a verification. A scan sees what anyone online can see, so it never proves a whole requirement is met.

## Fix it with your AI

Most sites can use the same value modern browsers default to, set on purpose.

:::fix-prompt any
Add Referrer-Policy: strict-origin-when-cross-origin to every page of my site through my host or framework config. Then search my code for any link or redirect that puts a token, email address or other private value in a URL query string, and list them so I can move those values out of the address.
:::

## How to check

Say Atlas, our example app at `atlas.example`, puts a password reset token in its reset link. An explicit policy keeps that address from being shared with other sites, and moving the token out of the address is better still.

The free [quick check](/check) covers this on your homepage with no account, and a Pulse scan from your account adds your scripts and public records. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains the difference.

## Questions people ask

### If browsers have a safe default, why set it?

Because older browsers and some embedded views use a looser default, and an explicit setting makes your intent clear to anyone reviewing the site.

### Which value should I use?

strict-origin-when-cross-origin suits most sites. Use no-referrer if you never want other sites to learn where a visitor came from.

## Sources

- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07
- [Referrer-Policy header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy), MDN Web Docs, read on 2026-10-07