A page URL can contain a search term, document identifier or other context that should not travel to every linked service. Referrer-Policy controls how much referrer information a browser supplies for requests governed by that policy. It helps limit disclosure, but it does not remove sensitive values from the URL itself.
Begin by deciding whether destinations need the full referring URL, only its origin or no referrer. Then test same-origin requests, cross-origin requests and secure-to-insecure transitions separately. A single clicked link does not exercise every policy case.
Distinguish the policy from the request header
The response header is spelled Referrer-Policy. The historical request header is spelled Referer. The policy influences the information the browser includes in that request header, subject to the request's context and browser behaviour.
The Referrer-Policy analyzer reviews a pasted policy value and describes its intended disclosure behaviour. It does not navigate to another site or observe the headers that a remote service received. Use network evidence for those separate questions.
A referrer normally excludes credentials and the fragment portion of a URL under web-platform processing rules. Paths and query strings can still matter under policies that permit fuller disclosure. Do not assume that because fragments are excluded, every sensitive URL component is protected.
Choose the disclosure level deliberately
no-referrer requests omission of referrer information. origin limits it to the origin. same-origin supplies referrer information only for same-origin requests. strict-origin-when-cross-origin combines fuller same-origin information with origin-only cross-origin disclosure and restrictions on downgrade cases.
Other values express different tradeoffs, including policies that can send more information across origins. Review the current semantics for the exact value you use. A familiar word such as strict is not a substitute for understanding the same-origin, cross-origin and downgrade cases.
A common modern browser default is strict-origin-when-cross-origin, but setting an explicit policy makes the application's intent reviewable and avoids relying solely on defaults. Test supported environments and any element-level overrides used by the application.
| Policy | Typical intent | Review point |
|---|---|---|
| no-referrer | Do not provide referrer information | Check integrations that rely on attribution |
| origin | Provide the source origin | The origin itself can reveal context |
| same-origin | Restrict disclosure to the same origin | Same-origin logs can still receive path and query |
| strict-origin-when-cross-origin | Use fuller local and reduced external disclosure | Review same-origin sensitive URLs |
| unsafe-url | Permit broad URL disclosure under its rules | Usually inappropriate for sensitive paths or queries |
Trace a document link leaving the site
Suppose a user reads https://app.example/reports/quarterly?team=finance and follows a link to an external help service. Under a suitable origin-only cross-origin policy, the destination can receive the source origin without the report path and team query. Under a more permissive policy, more of that context may leave the site.
Test with synthetic identifiers and an endpoint you control. Inspect the outgoing Referer header in developer tools and the receiving server's record if available. Keep the final destination and redirect chain in the test because the navigation may not go directly to the linked host.
Now test a same-origin API or image request from that page. A policy that reduces cross-origin disclosure can still permit fuller same-origin referrer information. That may be acceptable, but it means internal access logs and analytics need their own data-handling review.
The stronger architectural fix is to avoid putting secrets such as session tokens or reset credentials into ordinary reusable URLs where possible. Referrer policy limits one disclosure route; history, copied links, server logs and screenshots can expose the URL through other routes.
Check which policy applies to each resource
A document can receive policy through an HTTP header or a supported meta declaration. Some elements and fetch operations also support referrer-policy controls. A link-specific setting can make its behaviour differ from the document's general policy.
Inspect rendered markup, not only source templates. Framework components and third-party widgets may set their own attributes. For fetch calls, review the request options. A page-level configuration review can miss a programmatic request that explicitly selects a different policy.
Stylesheets and their subresources have policy details of their own. If an image loaded from CSS behaves differently from an ordinary image element, trace the resource's request context and the policy associated with its initiator. The same destination URL can be requested through different paths.
Include redirects in the evidence
A navigation can pass through an attribution service or a login redirect before reaching its final destination. Review the headers on each request and any policy delivered along the chain. Looking only at the final address bar can hide an earlier request that already disclosed information.
Use the browser's preserve-log option for a controlled test so navigation does not erase the evidence. Remove sensitive content before sharing a network archive. Referrer debugging itself can create a report containing the URLs you are trying to protect.
If an integration claims to require the full referrer, ask which field it actually uses. Origin-level attribution or an explicit non-sensitive parameter may be sufficient. Avoid granting broad disclosure without a concrete requirement and a review of the receiving service.
Do not use referrer as authentication
A missing or unexpected referrer can result from privacy settings, policy or request context. Non-browser clients can also construct requests differently. The header is not a secret and should not be the sole proof that a user or request is authorised.
Use proper authentication, authorisation and CSRF controls for state-changing operations. Referrer and Origin checks can play roles in a broader design, but their absence and trust assumptions must be handled deliberately. Do not break legitimate privacy-conscious clients merely because a referrer is unavailable.
Keep policy changes separate from access-control changes. If tightening disclosure breaks an endpoint that relied solely on a referrer string, repair the endpoint's trust model rather than weakening every page's privacy policy to preserve that assumption.
Verify the public response and the user flows
Check the header at the CDN or reverse proxy that visitors actually reach. An origin can emit one value while an edge adds another. Review multiple response paths, including redirects and errors, and understand how multiple policy tokens are interpreted by supported browsers.
Test outbound links, embedded resources, login transitions and downloads. Record the expected disclosure for each. A policy should be chosen according to the data involved and the required flow, rather than by aiming for a generic security-header score.
After deployment, compare controlled requests with the expected matrix. Keep browser version and policy source in the record. If the observed header differs, inspect overrides and initiators before assuming that the browser ignored the policy.
Keep a minimal receiving endpoint for regression tests
A controlled endpoint that records only the relevant request headers can make policy testing reproducible. Use a synthetic source URL with a recognisable path and query marker, then navigate or load a resource from the test page. Compare the received Referer with the expected origin or omission. Keep this endpoint restricted to testing and avoid retaining unrelated visitor data. Repeat with the same-origin case and a redirect so the test covers more than one path. If the result changes after an infrastructure update, the saved policy and request matrix show exactly which disclosure rule changed.
Frequently asked questions
Does no-referrer hide my IP address?
No. It controls referrer information, not the network source address or every other request header. The destination still receives the request through the network path in use. Keep URL-context disclosure separate from IP visibility and other privacy questions.
Is the fragment sent in Referer?
Web referrer processing excludes the fragment, but that does not make fragments suitable for arbitrary secrets. Page scripts, copied URLs and screenshots can still expose them. Choose a data design that limits sensitive URL content rather than relying on one header rule.
Why did a same-origin request include the path?
Some policies deliberately allow fuller same-origin referrer information while reducing cross-origin disclosure. Inspect the exact policy and origin relationship. If even internal path disclosure is inappropriate, choose a stricter policy and review internal logging as well.
Can a link override the document policy?
Supported element-level controls can affect the link's request behaviour. Inspect the actual rendered element and browser result. A document header alone is not a complete inventory when components set their own referrerpolicy attributes or request options.
Does the analyzer contact the destination?
No. It reviews the policy text locally. To verify a received header, use a controlled browser request and an authorised receiving endpoint. Keep the distinction between intended policy semantics and observed network behaviour in the report.
Should analytics require the full referring URL?
Review the specific measurement need and data minimisation requirements. Origin-level information or explicit non-sensitive campaign data may suffice. Full URLs can contain user or document context, so broad disclosure should follow a concrete requirement rather than an inherited default.
What is a useful regression test?
Use synthetic URLs containing recognisable path and query markers, then inspect same-origin, cross-origin and downgrade cases. Include a redirect and an overridden element if the application uses them. Verify which markers arrive rather than only asserting that a header exists.