In one paragraph
A missing Referrer-Policy header means the response does not explicitly declare how much referring URL information browsers should send. Modern browsers generally default to strict-origin-when-cross-origin, so absence alone does not prove a full-URL leak. Set a deliberate policy, use tighter controls for sensitive pages where needed, and verify both same-origin and cross-origin requests in the browser.
Why it matters
The Referer request header tells a destination where a request came from. Depending on the effective policy, it can contain the source origin alone or also the path and query string. URL fragments and user credentials are not included in this header.
That distinction matters when URLs carry invitation codes, reset tokens, private report identifiers, or other sensitive data. A permissive policy can disclose more of a URL than the destination needs. Referrer controls reduce that channel of disclosure; they do not remove secrets from server logs, browser history, copied links, or the page itself.
Modern browsers normally use strict-origin-when-cross-origin when no policy is declared. Same-origin requests can receive the full referring URL, cross-origin requests at the same security level receive the origin only, and HTTPS-to-HTTP requests omit it. Older advice describing every missing header as automatic full-path leakage to all third parties overstates current behaviour.
How WebAuditOS evaluates this finding
The supplied check fails HTML responses missing the header. It warns for unsafe-url and the documented non-strict origin-when-cross-origin pattern; other declared values pass this targeted rule. Non-HTML responses and requests without a response are not graded.
The check does not validate every possible policy's strength or reproduce browser requests. A weaker historical value can pass if it falls outside the warning pattern. A policy declared in HTML or on an individual element can affect browser behaviour without satisfying this response-header check. Treat the finding as a configuration prompt, not evidence of a confirmed token leak.
How to fix it
- Choose the intended behaviour. For many public sites, this is a practical explicit baseline:
Referrer-Policy: strict-origin-when-cross-originIt preserves full referring URLs internally, provides only the origin for qualifying cross-origin requests, and omits referrers on a downgrade from HTTPS to HTTP.
- Consider stricter routes. no-referrer omits the header, while same-origin permits referrer information only within the same origin. A password reset or private report page may justify a tighter policy, especially if full internal referring URLs would expose tokens to other application routes or third-party-operated services behind the same origin.
- Set the header consistently at the response-producing layer. For nginx, a basic example is:
add_header Referrer-Policy "strict-origin-when-cross-origin" always;For Apache with the headers module:
Header always set Referrer-Policy "strict-origin-when-cross-origin"Integrate the setting with your existing configuration, checking inheritance, route overrides, and CDN transforms. Avoid sending competing values unintentionally.
- Review page and element overrides. A meta referrer policy, referrerpolicy attribute, or rel="noreferrer" can change individual request behaviour. Ensure sensitive pages do not unexpectedly use a looser element-level policy. Do not assume that inspecting one response header captures every request's effective policy.
- Verify what is actually sent. In DevTools, inspect controlled same-origin and cross-origin requests initiated by a test page. Check the Referer request header as well as the document's Referrer-Policy response header. Use non-sensitive test parameters, not real reset tokens. Extensions, browser privacy settings, and destination behaviour can further reduce the information sent.
- Test attribution and integrations, then rescan the affected HTML pages in WebAuditOS. Preserve campaign tracking through an intentional design rather than globally exposing complete referring URLs to satisfy one vendor.
What the fix can break
Changing to no-referrer or same-origin can remove referral information expected by partner analytics or cross-domain reporting. strict-origin-when-cross-origin generally retains the origin on qualifying HTTPS cross-origin requests, but not a detailed path.
Subdomains are different origins. Navigation from www.example.com to app.example.com therefore does not receive a full cross-origin referring path under that baseline simply because both belong to your business.
Some services incorrectly depend on referrer text as an access check or routing signal. Test them, but do not treat the header as robust authentication. Avoid putting confidential data into URL parameters as a substitute for properly designed integration state. A referrer policy only limits one route by which a URL can escape.
Questions
Do browsers already apply a safe default?
Modern browsers generally default to strict-origin-when-cross-origin. An explicit header makes the intended policy visible and consistent with your deployment, but a missing header alone does not establish a leak.
Does strict-origin-when-cross-origin hide query strings from my own site?
No. Same-origin requests can receive the path and query string. Use a tighter policy when those details should not travel even to other routes on the same origin.
Should I use no-referrer everywhere?
It is a valid privacy-focused choice, but it removes attribution some integrations rely on. Choose based on your data and integrations, rather than on which value happens to pass a scanner.
Which related checks should I review?
Review cookies missing Secure and missing X-Content-Type-Options, or use the security headers guide. They cover separate controls, not substitutes for referrer handling.