Referrer-Policy tells the browser how much referrer information to send when a user follows a link or loads a resource. It can limit leakage of full URLs, paths or query strings to other sites. Security teams use it to reduce exposure of sensitive identifiers in request metadata and to align browser behaviour with privacy requirements.
What Referrer-Policy controls in the browser
Referrer-Policy is a response header that tells the browser how much referrer data to include when it navigates to another origin or fetches subresources. The important behaviour is not just whether a referrer is sent, but whether the browser sends the full URL, only the origin, or nothing at all. That makes it a privacy and exposure control, not an authentication control.
It matters because referrer data can unintentionally reveal path names, search terms, tenant identifiers, or other URL embedded values to third-party sites and embedded resources. A policy lets you reduce that leakage without changing the destination itself.
How browsers decide what to send
The browser evaluates the active policy for each request and then computes the referrer value it is allowed to disclose. The policy can apply globally through a header, or locally through HTML metadata, but the browser still makes the final decision based on the configured policy and the request context. In practice, same-origin navigation usually preserves more context than cross-origin navigation.
That decision is shaped by two things: where the request is going, and which policy value is in force. A strict policy can suppress the referrer entirely, while a more permissive one may send only the origin. This is why the header is useful for balancing analytics and privacy with a smaller exposure footprint.
For teams rolling out headers at scale, the safest starting point is to follow a security headers guide and set Referrer-Policy alongside the rest of the browser hardening bundle. That keeps the policy aligned with CSP, HSTS, and cookie protections instead of treating it as an isolated tweak.
Where it helps, and where teams misread the risk
Referrer-Policy is most valuable when URLs may contain sensitive context that should not leave your site in request metadata. It is also useful when third-party content, tracking pixels, or off-site redirects are unavoidable and you want to limit what those recipients can observe. The control is preventive, so it should be used before you discover that referrer leakage is happening.
The common mistake is to assume that a less revealing referrer means the underlying URL is safe to expose elsewhere. It does not. If a page URL itself contains sensitive information, the best fix is to remove that data from the URL design first, then use Referrer-Policy to reduce residual leakage. The browser header is a containment measure, not a substitute for good URL hygiene.
Risk and Threat Considerations
Referrer leakage can disclose sensitive application structure, user journey details, or tokens and identifiers embedded in URLs to parties that should not receive them. The exposure is often unintentional, but it becomes materially worse when URLs carry account identifiers, session-like values, or privileged workflow context.
Failure mechanism: A browser follows a link or loads a third-party resource and includes more referrer detail than the organisation intended, because the active policy is missing, too permissive, or overridden by page-level behaviour.
Impact: External sites, analytics services, or embedded vendors can infer internal paths, user actions, or sensitive parameters, which can aid privacy harm, targeted abuse, and recon through application structure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.24 — Use of Cryptography | Covers protecting sensitive data in transit and reducing disclosure risk from browser-originated requests. |
| A.5.15 — Access control | Supports limiting disclosure of information to only the parties that need it. | |
| Recommendation — Apply A.8.24 to protect sensitive request data and minimise unnecessary exposure in transit. Apply A.5.15 to restrict unnecessary information disclosure through browser requests. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Referrer-Policy reduces data leakage across trust boundaries in web requests. |
| SC-8 — Transmission Confidentiality and Integrity | Relevant because referrer data is transmitted as part of browser request metadata. | |
| Recommendation — Use SC-7 to limit cross-boundary disclosure of sensitive request metadata. Use SC-8 to protect sensitive metadata transmitted in browser requests. | ||
| NIST CSF 2.0 | PR.DS-02 — Data in Transit is Protected | Referrer-Policy is a privacy control that reduces exposure of data sent during web navigation. |
| Recommendation — Protect data in transit by limiting referrer information sent to other origins. | ||
Practitioner Guidance
What to verify: Check the actual network requests your pages generate, not just the header value you expect. You want to confirm that cross-origin traffic receives only the intended level of referrer detail, especially on login, checkout, account, and support flows where URLs are most likely to expose sensitive state.
Decision rule: If a URL contains information you would not want logged or replayed by another origin, treat that as a URL design issue first and a referrer policy issue second. Use the header to reduce exposure, but remove sensitive data from the URL whenever you can.
Practitioner takeaway: Referrer-Policy is effective when it is part of a broader browser-exposure strategy, because the control limits disclosure from navigation, but it cannot make an unsafe URL structure safe.