What is Referrer-Policy?
Referrer-Policy is a security and privacy header that controls how much information your site reveals about where a visitor came from. Every time a browser follows a link or loads a resource, it can send a Referer header naming the page the request originated from. Referrer-Policy lets you decide exactly how much of that address, if any, is shared. Get it wrong and you can quietly leak private URLs to third parties; get it right and you protect both your users and your own systems.
What Referrer-Policy controls
The Referer header, misspelled in the original web standard and kept that way ever since, tells the destination which page sent the visitor. That is useful for analytics, but it can also expose sensitive data. If a logged-in user follows an external link from a page whose address contains a password-reset token, a session identifier or an internal path, that full URL can be handed to a site you do not control. Referrer-Policy is how you cap that exposure at a level you are comfortable with.
Why Referrer-Policy matters for security
URLs are not secrets, yet applications routinely put sensitive values in them. A leaked referrer can reveal account identifiers, one-time tokens, search queries or internal hostnames that help an attacker map your infrastructure. Tightening Referrer-Policy is a cheap, site-wide way to stop that data walking out of the door with every outbound click and every third-party asset your pages load.
The values Referrer-Policy accepts
- no-referrer sends nothing at all, the most private option.
- same-origin sends the full address to your own pages but nothing to other sites.
- strict-origin sends only your domain, and only over a secure connection.
- strict-origin-when-cross-origin sends the full address within your own site, just the domain to other sites, and nothing when security is downgraded. This is the modern browser default and a sensible choice for most sites.
- unsafe-url always sends the full address to everyone, which you should avoid.
If you are unsure, strict-origin-when-cross-origin gives a strong balance of privacy and working analytics. Sites handling sensitive accounts often go further and choose no-referrer or same-origin.
How to set Referrer-Policy
You can send it as an HTTP response header from your server, which applies it site-wide, or set it per page with a meta tag in the document head. The header approach is cleaner and harder to forget. On Apache add a Header directive, on Nginx add an add_header line, and on WordPress send it through the send_headers action or a security-headers plugin. Choose one value and apply it consistently across the whole site so behaviour is predictable.
Referrer-Policy and your other headers
Referrer-Policy works best as part of a complete set of response headers rather than in isolation. It pairs naturally with a Content Security Policy, HSTS and a sensible Permissions-Policy to form a defence-in-depth baseline. Our overview of website security headers explained shows how they fit together, and each EzyAudit AI scan grades them side by side.
How to check your Referrer-Policy
The value is invisible to visitors, so the practical way to verify it is to inspect your live headers. Run a security scan with EzyAudit AI and you will see whether Referrer-Policy is set, whether the value leaks more than it should, and what to change. Every finding includes a clear explanation and a recommended value. See the full list of checks we run. For the complete list of values and how browsers apply them, the MDN reference for Referrer-Policy is the definitive source.
A well-chosen Referrer-Policy protects your users and keeps sensitive URLs out of other companies’ logs. Scan your website now to see what your site is currently leaking.