Referrer-Policy: Stop Leaking Sensitive URLs

Every time a user clicks from your app to a third-party link, the browser may send a Referer header with the full URL they came from—including path segments, query strings and sometimes one-time tokens. Password-reset links, signed download URLs, invite codes and internal admin paths have all leaked this way into analytics vendors, CDNs and support widgets. Referrer-Policy is the response header that decides how much of that URL other origins are allowed to see. Set it wrong (or leave the browser default) and you quietly ship secrets to whoever sits at the other end of the click.

I build PixelValut, a set of browser-side developer and security tools, and I wanted a practical checklist for teams that already ship HTTPS but never audited what their pages put in Referer. I wrote this with help from AI tools and checked every command and claim myself. This piece covers the policy values that matter, real leak scenarios, how to set and verify the header with curl and DevTools, and a safe default for most SaaS apps.

Direct answer: Referrer-Policy tells browsers how much of the current page URL to put in the Referer header (and in document.referrer) when the user navigates or loads a subresource. Policies range from sending nothing (no-referrer) to sending the full URL even on HTTPS→HTTP downgrades. Pick a value that keeps path and query off cross-origin requests unless you truly need them for analytics.

Modern Chrome, Firefox and Safari effectively default to strict-origin-when-cross-origin when the site sends no policy. That is better than the old no-referrer-when-downgrade default, but it still sends your full path and query to other pages on the same origin, and your origin (scheme + host + port) to other HTTPS sites. If a reset link lives at https://app.example.com/reset?token=… and the user clicks a cross-origin help article, the token stays off the wire—only https://app.example.com/ is sent. If that help widget is same-site or you used unsafe-url, the token can leave the browser.

Treat these as design cases, not one-off bugs:

Referer unless the policy strips them./admin/users/123/impersonate). Even without tokens, path leakage tells an external script who you were looking at.unsafe-url and older defaults are how full URLs end up on cleartext hops. This sits next to transport controls like MTA-STS for inbound email and certificate issuance limits via CAA records and CT logs: each closes a different disclosure channel. Referrer policy closes the browser-navigation channel.

Nginx (inside the server block):

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

Cloudflare Transform Rule or Response Header modification:

Set Referrer-Policy = strict-origin-when-cross-origin

Laravel middleware (global):

public function handle($request, Closure $next)
{
    $response = $next($request);
    $response->headers->set(
        'Referrer-Policy',
        'strict-origin-when-cross-origin'
    );
    return $response;
}

You can also set a document-wide default with HTML, useful on static sites:

<meta name="referrer" content="strict-origin-when-cross-origin">

Prefer the HTTP header for APIs and redirects. For a single sensitive view (reset confirm, billing portal), tighten further:

Referrer-Policy: no-referrer

HTML links can override per navigation with the referrerpolicy attribute or rel="noreferrer":

<a href="https://partner.example/docs" referrerpolicy="no-referrer">Docs</a>
<a href="https://partner.example/docs" rel="noreferrer">Docs</a>

rel="noreferrer" also implies noopener behavior for browsing context, which pairs well with the reverse-proxy hardening patterns in zero-trust nginx setups.

Check that the response advertises the policy:

curl -sI https://pixelvalut.com/tools/ | grep -i referrer-policy

You want a line like:

referrer-policy: strict-origin-when-cross-origin

In Chrome DevTools:

referrer-policy. referer.?token= or /reset/. For a quick browser-side pass on any URL, use the PixelValut HTTP Status Checker to inspect response headers without installing anything. Then repeat the navigation test in DevTools—header presence alone does not prove outbound requests are stripped; you still need to watch a real cross-origin click.

strict-origin-when-cross-origin no-referrer or same-origin curl -sI and a DevTools cross-origin click For most product apps, yes as a default. It keeps path and query off cross-origin requests and strips referrers on HTTPS→HTTP downgrades. Sensitive flows (password reset, impersonation, billing) still deserve no-referrer or same-origin.

It can reduce the path-level detail third parties receive. Origin-only or missing referrers are common under modern defaults. If you need campaign attribution, put UTM parameters on links you control and accept that full-path referrers to arbitrary third parties are not worth the leak.

The header (or meta tag) sets a document default. rel="noreferrer" and the referrerpolicy attribute override per link. Use the header globally, then override on specific outbound anchors.

Yes. fetch, XHR and subresources send Referer according to the policy (and the request's referrerPolicy option). A global header covers navigations and most subresources; explicit referrerPolicy: "no-referrer" in fetch helps for sensitive XHRs.

You can, if you do not rely on inbound referrers for security or analytics. Many teams prefer strict-origin-when-cross-origin site-wide and no-referrer only on secret-bearing pages so first-party analytics still see full same-origin paths.

Open a staging page whose URL contains a dummy ?token=test, click a cross-origin link or load a cross-origin image, and inspect the outbound Referer in DevTools. Repeat after setting the header until the token disappears from cross-origin requests.