Defaults.Exposed › Fixes › Referrer-Policy

How to fix Referrer-Policy

A Referrer-Policy is a one-line instruction your website hands to every visitor's browser, controlling how much of your web address travels with them when they click a link to another site. Without it, the full address of whatever page they were on — search terms, account numbers, reset links, internal page paths and all — is quietly handed to the next site they land on, including advertisers, analytics firms, and anywhere else a link points.

Bottom line for your business: Every time a visitor clicks an outbound link, ad, or shared resource, their browser can hand the full address of your page to the destination — and if your addresses carry search queries, customer IDs, order numbers, or one-time links, you are leaking customer data to third parties you do not control. That is a data-protection problem regulators take seriously, a privacy promise quietly broken, and a graded gap a client's security team will flag during due diligence.

What this can cost you

• A customer fills in a form or runs a search, then clicks an outbound link or ad — and the page address, complete with what they typed, is handed straight to an advertiser or analytics firm you never meant to share it with.
• Password-reset and account-confirmation links sometimes carry a secret token in the web address; without this header, clicking any link on that page can pass the whole address — token included — to an outside site.
• Private internal page paths (admin areas, customer-only pages, pricing tiers, document links) are revealed to every third party your visitors click through to, handing competitors and snoops a map of your site they should never see.
• A client's security review or a privacy audit scans your site, sees no Referrer-Policy, and logs it as a data-minimisation failure — the kind of finding that stalls a contract or a certification.
• Personal data ends up in the hands of processors you have no agreement with, turning a five-minute oversight into a reportable data-protection breach.

Why it matters. Browsers, left to their own devices, are chatty: by default they tell the next website where a visitor just came from, often including the full address of the page. For a brochure site that may be harmless, but the moment your addresses contain anything personal — a search term, an order ID, an email in a link, a private path — that default quietly leaks it to outside parties. A Referrer-Policy is the single setting that tells browsers to stop oversharing. It is a graded check on your scorecard worth real points, it maps directly to data-minimisation duties under privacy law, and it is one of the standard security headers any professional review expects to find.

What this is, in plain words

Every time a visitor on your website clicks a link to another site — an outbound link, a banner ad, a “share this”, even a font or image loaded from elsewhere — their browser quietly attaches a note saying which page of yours they came from. That note is called the referrer.

Used sensibly, the referrer is harmless and even helpful: it is how other sites know that traffic came from you, and it powers a lot of honest analytics. The catch is in the default behaviour. Left unmanaged, the browser does not just say “they came from your-business.com” — it often hands over the full address of the exact page, including everything after the domain name. And web addresses carry far more than people realise: search terms typed into your site, order and account numbers, the path to a private members-only page, even one-time secret tokens in password-reset and confirmation links.

A Referrer-Policy is a single instruction your website sends to the browser that says how much of that note it is allowed to share. You can tell it to share only your domain name, only to other pages on your own site, or nothing at all. Think of it as the difference between handing a stranger your full home address with your daily schedule attached, versus just telling them which town you live in.

This is one of a small family of “security headers” — short instructions your site gives every visitor’s browser. It does not change how your site looks or works. It simply stops the browser from oversharing on your behalf.

What this can cost you

Here are concrete, everyday ways a missing or permissive Referrer-Policy bites real businesses. None of these require a hacker — they happen automatically, every day, in normal use.

• The leaked search. A customer searches your site for something sensitive — a medical product, a debt-related service, a competitor comparison — and the search term lands in the page address. They then click an outbound link or an ad on that results page. The advertiser now receives your address with the search term in it, learning exactly what your customer was looking for. You never agreed to share that, and you cannot take it back.

• The exposed reset link. Many systems put a secret one-time token in the address of password-reset, email-confirmation, or “magic login” pages. If that page contains any outbound link or third-party resource, the full address — token included — can be handed to an outside site. In the worst case that hands a third party the keys to an account.

• The site map you gave away for free. Your internal page paths often reveal your structure: /admin, /enterprise-pricing, /clients/acme, /downloads/private-report. Without this header, every outside site your visitors click through to receives those paths. Competitors learn your pricing tiers and product lines; scrapers learn which pages to target.

• The unwanted data-sharing relationship. Privacy law expects you to know who your customers’ personal data goes to and to have an agreement in place. Leaking page addresses that contain customer IDs or email addresses to ad networks and analytics firms — with no agreement and no consent — is exactly the kind of uncontrolled data flow that turns a routine audit into a finding, and a finding into a reportable breach.

• The deal that stalls on due diligence. When a larger customer’s security team reviews you, missing standard security headers is a quick, automated tick-box. Seeing Referrer-Policy absent tells them basic privacy hygiene was never set up — and that impression colours everything else in the review.

What it actually is

By default, browsers follow a behaviour roughly equivalent to “strict-origin-when-cross-origin” on modern versions — but you cannot rely on that, because older browsers, embedded webviews, and certain configurations still fall back to leaking more. The only way to be sure is to set the policy explicitly. When you do, you are choosing one rule from a short list. The ones that matter:

• no-referrer — share nothing. The next site is told nothing about where the visitor came from. Maximum privacy; can dampen your referral analytics.
• same-origin — share the full address only when the visitor moves between pages on your own site; share nothing with outside sites.
• strict-origin-when-cross-origin — the recommended default. Within your own site, the full path is shared; to outside sites, only your bare domain name is shared (and nothing at all when going from a secure page to an insecure one). Outside parties learn the traffic came from you, but never the private details after your domain.
• origin — always share just your domain name, even within your own site.

And the two values to avoid, because the scorecard treats them as no better than having no header at all:

• unsafe-url — share the full address with everyone, always. This is the worst case in a single word.
• no-referrer-when-downgrade — the old browser default; it still sends the full address to other secure sites, leaking everything described above.

What “good” looks like: a Referrer-Policy header is present and set to a restrictive value — for most businesses, strict-origin-when-cross-origin. This keeps referral analytics working while ensuring nothing past your domain name ever reaches an outside site.

How to fix it (free, about 5 minutes)

Hand this section to your IT person, web developer, or hosting support — the fix is free, it is a single line, and it will not break your site. There is no risky rollout here: unlike some security settings, a sensible Referrer-Policy cannot stop your links or pages from working. It only trims what gets shared with other sites.

The goal: set a Referrer-Policy response header with the value strict-origin-when-cross-origin (or a stricter value if you prefer to share even less).

Cloudflare (no code — easiest if you use it): Dashboard → your domain → Rules → Transform Rules → Modify Response Header → Create rule → Set static → Header name Referrer-Policy, value strict-origin-when-cross-origin → apply to all incoming requests → Deploy.

Google Workspace / Microsoft 365: these manage your email, not your website, so the header is set wherever your site is actually hosted (your web host, CDN, or server) — not in Workspace or 365 admin. Identify the host and use the matching option below.

Nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache (in the site config or .htaccess):

Header always set Referrer-Policy "strict-origin-when-cross-origin"

IIS (web.config):

<httpProtocol><customHeaders>
  <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>

Node / Express:

app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });

WordPress / common hosts: most managed WordPress and shared hosts let you add response headers either through a security plugin, a “headers” panel in the hosting control panel, or the .htaccess snippet above. If you are behind Cloudflare, the Cloudflare method is the cleanest and applies everywhere at once.

After applying: load your site and re-run the check, or use your browser’s developer tools (Network tab → click the main document → Response Headers) to confirm Referrer-Policy: strict-origin-when-cross-origin is present.

Common mistakes

• Setting a permissive value and assuming it counts. unsafe-url and no-referrer-when-downgrade both still leak the full address. The scorecard scores them zero — identical to having no header. If the header is present but the points are not, this is almost always why.
• Setting it on the homepage only. The header should be sent on every page, because the leaks happen on search-results, account, and reset pages — not the homepage. Set it at the server, CDN, or Cloudflare level so it applies site-wide automatically.
• Setting it in HTML <meta> tags only. A <meta name="referrer"> tag works for some cases but not all, and is easy to get inconsistent across pages. Setting it as a proper response header (the methods above) is the reliable approach.
• Letting one layer override another. If both your origin server and your CDN set the header with different values, the result can be unpredictable. Pick one place to manage it — usually the CDN or Cloudflare if you have one — and keep the rest consistent.
• Treating it as a substitute for keeping data out of URLs. The header limits the damage, but the cleaner long-term habit is not to put secrets and personal data in web addresses in the first place. Use the header now; raise the URL hygiene with your developer as a follow-up.

A quick note on the related headers

Referrer-Policy sits alongside a small set of other web security headers we check — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, and a few advanced cross-origin headers. They protect different things, so having one does not cover the others. If your Referrer-Policy is missing, it is worth asking whoever fixes it to confirm the other standard headers are in place at the same time, since they are typically configured in the same one place and the visit costs nothing extra.

In short

Referrer-Policy is the cheapest, safest privacy fix on your scorecard: one line, about five minutes, no risk of breaking anything, and free. It stops your visitors’ browsers from quietly handing your private page addresses — and whatever personal data they contain — to every outside site they click through to. Set it to strict-origin-when-cross-origin, confirm it is live on every page, and the medium-severity gap and its 15 points are closed.

FAQ