Referrer Policy Checker

Analyze your Referrer-Policy configuration. Stop inadvertently sending sensitive search queries, unencrypted IDs, and password reset tokens to third-party servers.

Use this guide to understand the issue, validate the problem manually, and run the live scanner when you are ready. Get results in under 30 seconds.

Run the scanner for this issue

The fastest way to confirm this issue on a live domain is to run the dedicated scanner. It checks the technical signal directly, then shows the finding in plain language with remediation context.

Run Referrer Policy Check Run Full Privacy Audit

Why teams search for this check

Search intent around this topic usually comes from one of three pressures: a buyer or procurement questionnaire, a legal or compliance review, or an engineering team trying to validate a risky browser behavior before launch.

This page is written to answer that intent directly, without generic filler. It explains what the issue means technically, how to confirm it manually, and what a defensible fix looks like in production.

The hidden dangers of the Referer header

When a user clicks a link from your website to an external domain, their browser sends an HTTP `Referer` header to the destination. This header contains the exact URL they were just on.

If your URLs contain sensitive, unencrypted parameters, like a secret password reset token (`?token=123`) or a user's exact search query, that data is leaked directly into the logs and Google Analytics accounts of the third-party website owner.

Leaking sensitive user data to unauthorized third parties via the Referer header is a common, often overlooked security flaw that easily violates privacy laws like the GDPR and CCPA. In practice, teams usually do not lose trust because of a single configuration detail. They lose trust when the issue suggests weak governance, undocumented vendors, avoidable data sharing, or a disconnect between legal claims and live technical behavior.

What this tool specifically detects

Whether the site controls how much URL and origin information is sent to other domains when visitors click away.
Referrer-Policy gaps that can expose query parameters, reset links, or internal path structures to third parties.
Header configurations that fall short of enterprise hardening expectations.

When this becomes critical

You use reset links, invitation flows, checkout tokens, or other URL-based identifiers.
The site connects to multiple external vendors.
You need to demonstrate practical data minimization in browser behavior.

How this check works

Our referrer policy checker queries your website's HTTP response headers to see if you have explicitly defined a strict `Referrer-Policy`, analyzing whether the configuration prevents cross-origin URL data leakage.

The goal is not to create noise. The goal is to surface the signal that matters first, show you how the issue normally appears in production, and help you decide whether you need a quick fix, a deeper audit, or a broader policy update.

Real-world examples that trigger this finding

A password reset link includes a token in the URL and the full referrer is leaked to a third-party script.

Analytics or chat vendors receive full path details from sensitive sections because no referrer restriction is set.

A procurement review flags the site because it leaks full URLs to external domains by default.

How to manually detect this issue

Inspect the response headers for Referrer-Policy and note whether it is absent or too permissive.
Test external navigation from a sensitive page and observe what the destination receives as the referrer.
Review URLs for tokens, IDs, or personal data that should never leave the first-party context.

How to fix it

Adopt a safer default such as strict-origin-when-cross-origin unless a narrower policy is feasible.
Avoid placing sensitive information in URLs in the first place.
Recheck third-party redirects, support tools, and analytics flows after the change.

Common mistakes teams make

Assuming HTTPS alone prevents referrer leakage.
Keeping query parameters that contain operational or personal data.
Testing only the homepage instead of sensitive account or form flows.

Related Tools and Guides

Full Headers Scanner PII Exposure Scanner Tracker Detector Learn how Referrer-Policy reduces leakage Learn how third-party requests receive browser context

Frequently Asked Questions

What is the recommended Referrer-Policy?+

The modern best practice recommendation is `strict-origin-when-cross-origin`. It passes the full URL when navigating within your own site, but strips the path and query parameters (sending only the domain name) when navigating to external sites.

Will changing my Referrer-Policy break analytics?+

Internal analytics (like Google Analytics installed on your domain) will not break if you use `strict-origin-when-cross-origin`. However, if you rely on the full URL path being sent to an external, cross-domain partner, that specific data transfer will stop.

What happens if I don't set a Referrer-Policy?+

Historically, browsers defaulted to sending the full URL everywhere. Modern browsers (Chrome, Firefox, Safari) have recently changed their default behavior to `strict-origin-when-cross-origin` to protect privacy. However, you should still explicitly set the header rather than relying on shifting browser defaults.

Is it spelled 'Referer' or 'Referrer'?+

The original HTTP specification introduced a spelling error, so the HTTP request header is officially spelled `Referer` (one 'r'). The security policy response header, created much later, corrected the spelling to `Referrer-Policy` (two 'r's).

Can the Referrer-Policy stop third-party image tracking?+

Yes. When the browser loads a third-party image, script, or stylesheet, it also sends a Referer header. A strict policy prevents sensitive URL data from leaking to the servers hosting those external assets.

Need a broader privacy review?

Run the full SitePrivacyScore audit when you need more than a single point-in-time check. It combines trackers, cookies, headers, consent signals, and remediation guidance in one report.

Run Full Privacy Audit Browse All Free Tools

For deeper runtime checks, run the full privacy audit →