Referrer-Policy is missing or leaks full addresses

SeverityInfo

ScopeWhole site

EffortSmall

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_referrer_policy

Short answer

When a visitor follows a link or your page loads a third-party file, the browser sends a Referer header telling the other site where the request came from. Referrer-Policy controls how much of your address goes with it. Set strict-origin-when-cross-origin: other sites see only your domain, while your own analytics still sees full paths. Security headers do not affect Google rankings; this is about privacy.

Why it matters

Page addresses often carry more than you think: search terms, order or password-reset tokens, user IDs, campaign parameters, paths inside a members area. With unsafe-url or no-referrer-when-downgrade, the full address including the query string goes to every external site a page links to or loads from (ad networks, embedded widgets, CDNs) and ends up in their logs and analytics. A reset token leaked this way can be enough to take over an account.

Modern browsers already use strict-origin-when-cross-origin when no policy is sent, which is why a missing header is only Info. A weakening value is the real problem. There is no SEO effect either way.

How Glimana detects it

Glimana reads the response headers of your HTTPS home page (after redirects). No Referrer-Policy header is reported as Info. A policy whose effective (last) value is unsafe-url or no-referrer-when-downgrade is reported as Low, because both send the full address to other HTTPS sites. Any other value (strict-origin-when-cross-origin, strict-origin, same-origin, no-referrer and so on) passes. If the home page cannot be reached over HTTPS, the check shows Could not be measured.

How to fix it

Watch out

no-referrer is the strictest value, but it hides your site as a traffic source in partners' analytics and can upset payment or login providers that look at the Referer of a returning visitor. strict-origin-when-cross-origin is the balanced choice. On Nginx, an add_header inside a location block cancels every add_header inherited from the server block, so adding one header there can silently remove others.

Find the finding in Glimana. Open Security; this check is in the Security headers group, with the evidence from the last scan under its title. The same problem is listed under Issues › Referrer-Policy is missing or leaks full addresses.
Apply the fix on your platform.

WordPressCloudflareApache / Nginx

WordPress sends Referrer-Policy only on admin and login screens, not on the public site. On Apache or LiteSpeed hosting add near the top of .htaccess: Header always set Referrer-Policy "strict-origin-when-cross-origin" (needs mod_headers). Many security and header plugins have a field for it. If a page-cache plugin serves static files, the .htaccess route is more reliable than a PHP hook.

Rules › Overview › Create rule › Response Header Transform Rule. Apply it to all incoming requests, choose Set static, header name Referrer-Policy, value strict-origin-when-cross-origin, and deploy. The Managed Transform Add security headers (Rules › Settings) also sets this header, but to same-origin, which sends no referrer at all to other sites.

Apache, in the virtual host or .htaccess: Header always set Referrer-Policy "strict-origin-when-cross-origin". Nginx, in the HTTPS server block: add_header Referrer-Policy "strict-origin-when-cross-origin" always; then nginx -t && systemctl reload nginx.
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

After fixing, press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes as soon as the check passes.