Loading…
Loading…
Paste any URL you're authorized to test. Scorifya fetches the response and shows your Referrer-Policy header alongside the rest of your security headers, so you can see if referrers are controlled.
Free tool
The Referrer-Policy header controls how much of the current URL is sent in the Referer header when a visitor clicks through to another site. With no policy, browsers often send the full URL, which can leak tokens, session identifiers, or private paths to third parties like analytics and ad networks. A checker tells you whether a policy is set and whether it is strict enough.
Paste any URL you're allowed to test. Scorifya fetches the response and reports your Referrer-Policy header, present or absent, and whether it is a leaky value or a safe one like strict-origin-when-cross-origin. It sits inside the broader 0 to 100 hardening score, so you see the headers around it too.
This page is written for people searching for Referrer-Policy checker—same tool as the homepage, with context for that query.
How we differ from deep TLS graders, browser-focused posture tools, and header-only checkers: read the comparison.
Illustrative snapshots of what a report can look like—paste your URL above for a live score on your site.
Example A: no Referrer-Policy
TLS and most headers are fine, but no Referrer-Policy is sent, so full URLs can leak to the sites your pages link out to.
Referrer-Policy missing
Without a policy, a click from a URL that contains a token or a private path can hand that full URL to a third party via the Referer header. Set strict-origin-when-cross-origin as a safe default.
Example B: safe policy in place
Referrer-Policy is set to a safe value, so cross-site navigations only send the origin, not the full URL. The remaining points are elsewhere in the header set.
Referrer-Policy set safely
strict-origin-when-cross-origin sends the full path on same-origin navigations but only the origin cross-site, which is the right balance for most sites.
Set strict-origin-when-cross-origin as your default
This value keeps full referrers for your own pages (useful for analytics) but only sends the origin to other sites, so tokens and private paths in URLs do not leak. Set it once at your web server, reverse proxy, or framework.
Use no-referrer for the most sensitive pages
On pages where even the origin should not leak, like a password reset or a one-time link, set Referrer-Policy: no-referrer so nothing is sent at all.
Keep secrets out of URLs in the first place
A Referrer-Policy reduces leakage, but the stronger fix is to avoid putting tokens or identifiers in URLs at all. Prefer headers or POST bodies for anything sensitive.
Re-scan after the header change
Headers update on the very next response after a deploy. Re-scan immediately to confirm the policy is being sent with the value you expect.
For weights and penalties behind each category, see How Scorifya works.
Referrer-Policy is a response header that tells the browser how much of the current page's URL to include in the Referer header when the visitor navigates to another page or site. It ranges from sending the full URL to sending nothing, and it lets you stop full URLs (which may contain tokens or private paths) from leaking to third parties.
strict-origin-when-cross-origin is the safe default for most sites: same-origin navigations get the full path, cross-site navigations only get the origin, and downgrades from HTTPS to HTTP send nothing. Use no-referrer on especially sensitive pages where even the origin should not be shared.
Without a policy, many browsers send the full URL in the Referer header when a user clicks an external link. If your URLs contain session tokens, reset codes, or private paths, those can end up in the logs of analytics providers, ad networks, or any site you link to. A policy closes that leak.
Yes. Checking your Referrer-Policy (and running the full Scorifya scan) is free for any URL you're authorized to test. Pro adds higher rate limits, scheduled re-scans, watch lists with alerts, and exports.
No. Scorifya only fetches public, unauthenticated URLs. Header values can differ on authenticated routes, so test those during your own staging passes.
More detail on limits and billing: FAQ.
TLS, HTTPS & redirects
Valid certificates, modern TLS, and clean HTTP→HTTPS upgrades. We also probe whether legacy TLS 1.0/1.1 are still accepted.
Security headers
CSP, HSTS, and related headers reduce common browser-side attack surfaces and clickjacking risk.
DNS & email (passive)
SPF, DMARC, a few DKIM selectors, MX, and whether common subdomains resolve publicly—without port scanning.
Hygiene signals
Verbose server banners and risky defaults can raise your attack surface and erode trust.
Not a vulnerability scan
Scorifya checks public configuration signals; it does not attempt exploitation, port scans, or authenticated crawling.
If you're iterating on config or deploying changes, you'll likely run multiple checks as you tighten things up. When you're ready, Scorifya Pro removes scan limits and unlocks JSON/CSV/PDF exports.