URLs carry information in their paths and query strings. When a browser follows a link or loads a subresource, the Referer request header can disclose part of the source URL to another origin. Referrer Policy controls how much of that address is sent. It is a privacy and data-flow control, not a replacement for authorization or an anti-CSRF token.
The policy can be set with the Referrer-Policy response header, HTML attributes on links and resources, and related mechanisms. Values such as no-referrer, same-origin, strict-origin and strict-origin-when-cross-origin balance disclosure against analytics and compatibility needs. The unsafe-url value is intentionally named because it can expose full URLs across origins.
The common default in modern implementations reduces cross-origin information, but applications should not depend on an unstated browser default. Set a policy deliberately at the document level, then check attributes that override it. A single referrerpolicy="unsafe-url" on a sensitive link can defeat the page-level choice for that navigation.
The header is misspelled Referer for historical reasons. Do not use that spelling inconsistency as a reason to build a custom parser. Use the browser platform and server framework to apply a tested policy. When a server behind a proxy inspects the header, it should treat it as untrusted input and avoid logging full values that may contain tokens or personal data.
Referrer Policy does not stop cross-site request forgery. A cross-origin form can still send a request without receiving the response, and cookies may still be attached according to their scope. Use SameSite cookies, Origin checks, CSRF tokens where the architecture requires them, and explicit server authorization. Each control addresses a different path.
Neither does the policy remove secrets already present in a URL. Tokens in query strings can reach browser history, proxy logs, analytics services, screenshots and support tickets. If a URL contains a bearer secret, no referrer setting can withdraw it from all those copies. Treat the leak at the source: avoid putting reusable credentials in URLs.
Choose the policy by reading the data flow. A public documentation site may tolerate origin-only cross-site referrers. A tenant application with sensitive paths should prefer no-referrer or a policy that never sends the full path cross-origin. Embedded resources may need a different choice, so test their navigation and loading behavior.
Verification should use a controlled second origin and a request inspector. Check top-level navigation, redirects, images, scripts, forms and downloads. Confirm the Referer value for same-origin and cross-origin cases, and verify that the policy is present on error pages and dynamically generated documents, not only the home page.
The useful outcome is a documented decision about which URL components may cross which origin boundary. That decision becomes part of the privacy review, while CSRF and data authorization remain separate tests. A security program that reports Referrer Policy as a CSRF remediation has closed the wrong finding.