Security guide
Referrer-Policy, explained
Every link away from your site can carry the page the visitor came from. This guide covers what the browser sends by default, what each policy value changes, and why one value is the right answer for almost every site.
01 Why it matters
Your URLs are data too
When a visitor follows a link, the browser tells the destination which page they came from. The same happens for every image, font and script your page loads from somewhere else. Most of the time that is harmless. It stops being harmless as soon as your URLs carry something: a search term, an order number, a password reset token, the internal path of a document. All of it leaves your site in a header you never wrote, addressed to a server you do not control.
Current browsers already default to something reasonable and no longer send full referrers across origins. But a default is not a promise you can make to a customer, it differs between engines and versions, and it is not visible in a response. Setting the header explicitly makes the behaviour yours: the same everywhere, testable, and part of what a scan can confirm.
02 The values
Five values, one recommendation
no-referrer
What it does. Sends nothing at all. No destination ever learns which page the request came from, not even that it came from your site.
Why it matters. The safest value, and it costs you attribution: your own analytics and every partner who counts inbound traffic will record the visits as direct. Right for a banking area or a document portal, usually too much for a marketing site.
no-referrer same-origin
What it does. Sends the full URL for requests that stay on your own origin, and nothing for anything that leaves it.
Why it matters. Keeps your internal navigation measurable while giving third parties nothing at all. A good fit for an application behind a login whose paths carry identifiers.
same-origin strict-origin
What it does. Sends only the origin, so the bare domain and never the path, and drops the referrer entirely when a connection is downgraded from HTTPS to HTTP.
Why it matters. External sites learn that a visitor came from you, but not from where. Path, query string and any token inside them stay on your side.
strict-origin strict-origin-when-cross-origin
What it does. Sends the full URL within your own origin, only the origin to other sites, and nothing on a downgrade to HTTP.
Why it matters. This is the value to set. Your own analysis keeps the detail it needs, everyone else gets the bare domain, and no configuration mistake can push a path across the network in clear text.
strict-origin-when-cross-origin unsafe-url
What it does. Sends the full URL to everyone, on every request, including over unencrypted connections.
Why it matters. The name is a warning, not a style choice. Every query string you have ever put in a URL goes to every third party your pages touch. There is no situation on a public website where this is the right answer.
unsafe-url03 Rolling it out
One line, then the exceptions
Set the header once for the whole site in your web server. It applies to links, images, scripts and fetch requests alike, so there is no work per page. Then look at the two places that can still surprise you: a payment or analytics provider that expects a full referrer, and any link you deliberately want to be untraceable.
server { listen 443 ssl; add_header Referrer-Policy "strict-origin-when-cross-origin" always; }A single element can override the site-wide policy through its referrerpolicy attribute, and rel="noreferrer" on a link suppresses the header for that link alone. Use those for the exceptions instead of weakening the policy for everything else.
04 Questions
What people ask about the referrer
Does a strict policy break my analytics?
Not your own. strict-origin-when-cross-origin keeps the full URL for requests that stay on your origin, and that is what a first-party analytics script reads. What changes is the view external tools get: your domain instead of the exact page.
Is the header still needed if browsers already default to a safe value?
Yes, for two reasons. The default differs between browsers and versions, and a default is not something you can point at in an audit. An explicitly sent header is the same everywhere and shows up in a scan.
What about links to a payment provider?
Sending only the origin is enough for almost every provider, because the return address travels in the request itself rather than being read from the referrer. If one really needs more, set referrerpolicy on that one link instead of loosening the whole site.
Does Referrer-Policy protect the visitor or the site?
Both, from different angles. The visitor keeps their browsing history out of third-party logs, and you keep whatever your URLs happen to contain, which is more often something sensitive than teams expect.
05 In depth
Related security topics
The referrer is one of the things your pages give away. These guides cover the others.
HTTP security headers
What each response header does, which ones your site should send and how to configure them correctly.
Content Security Policy
The strongest defence against cross-site scripting: which directives to set, how to roll a policy out in report-only mode and how to reach an enforcing policy without breaking your site.
HSTS
Strict-Transport-Security explained: what max-age, includeSubDomains and preload actually do, and why the preload list is a decision you cannot quickly undo.
Cookie security
Secure, HttpOnly and SameSite: the cookie attributes that keep a session out of reach of scripts and cross-site requests, with the settings for a typical stack.
Clickjacking and X-Frame-Options
How an invisible overlay turns a visitor click into an action on your site, and the two headers that stop it: X-Frame-Options for older clients, frame-ancestors for everything else.
Permissions-Policy
Switch off camera, microphone, geolocation and payment for your site and everything it embeds: the allow-list syntax, and why a feature you did not name is not a feature you turned off.
SPF, DMARC and DNSSEC
The records that stop someone sending mail in your name, and the one that keeps your DNS answers honest: what each does and the order to introduce them in.
security.txt
The file that tells a researcher where to report a vulnerability. Two mandatory fields, ten minutes of work, and the difference between a private report and a public one.
Monitoring security headers
A header that is right today can be gone after the next deploy. Three ways to notice: a cron job with curl, a check in your CI pipeline and a scheduled scan, with what each of them catches and misses.
Detecting CSP changes
How a policy changes quietly through deploys, plugins and CDN rules, and how to catch it: a header diff, violation reports through report-to, and what a scan comparison can and cannot show.
Keep reading
More guides
Every guide stands on its own, and together they cover what our scanner looks at. Pick the one closest to your next question.
See which Referrer-Policy your site sends
Our free Quickscan reads the policy from your live response alongside the rest of your security headers, and explains every finding in plain language.