Start with the information that leaves
When a browser follows a link or loads an image, script or other resource, it may send a Referer request header to the destination. The spelling in that header is historical; the control is called Referrer-Policy. A small business can overlook this because the customer sees only a normal navigation. The destination may nevertheless learn where the request started. The meaningful unit of risk is the source URL: a path might reveal an account task or a private campaign, while a query string might contain a search term, an order reference or another value that should never have been placed in a URL. A policy can reduce what the browser sends, but it cannot make a sensitive URL safe to store in browser history, server logs or analytics. Begin with a map of pages where people sign in, view orders, submit enquiries, receive email links or leave for a payment or support provider. Record each external destination and why a referrer is wanted. Include embedded resources, not just visible links. This inventory turns a vague wish for privacy into a testable decision about particular customer journeys.
Choose the smallest useful disclosure
For an HTTPS site, the commonly used strict-origin-when-cross-origin policy sends the full source URL on same-origin requests, only the origin on HTTPS cross-origin requests, and no referrer on a downgrade to HTTP. MDN identifies it as the current browser default, but explicitly setting a deliberate policy makes deployment review easier. If external partners need only to know that traffic came from your domain, the origin-only cross-origin behaviour may be enough. If a page is especially sensitive, no-referrer omits the header altogether; same-origin retains referrers only within the same origin. Strict-origin also sends only the origin on suitable requests rather than the full same-origin path. These are different choices, not a ranking of website quality. Do not choose unsafe-url to satisfy a marketing attribution request: it can send the path and query even to an insecure destination. Also avoid assuming that every device, browser mode or third-party app will report referral data identically. Write down which business report relies on referrers, then ask whether campaign parameters on the destination side, server-side records you control or a less revealing policy will meet the actual need. A referral dashboard is not permission to expose customer page details.
Work through a customer journey
Imagine an online shop whose order-confirmation page links to an external delivery tracker. The confirmation URL contains a customer-specific reference in its query string. Under strict-origin-when-cross-origin, an HTTPS tracker on another origin should receive the shop's origin, not that confirmation path and query. Under no-referrer it should receive no Referer at all. The shop should still remove the customer-specific reference from a shareable URL where possible, because a copied URL, logs or a screenshot can expose it regardless of this header. The delivery link itself should carry only the opaque information the tracker actually needs, with access controls and expiry designed separately. Now compare an internal navigation from confirmation to order help: the default policy may carry the full source URL to the same origin, which could appear in internal logs. If that is unnecessary, a stricter page policy or cleaner URL may be appropriate. Finally test an external analytics image or embedded widget on the page. Requests for resources can carry referrers too, even though the customer did not click them. This example shows why the decision belongs to the entire page, its URL design and its embedded services rather than to the visible delivery link alone.
Set the policy at the right scope
The HTTP response header can set a document-wide policy. MDN also documents an HTML meta setting and a referrerpolicy attribute for individual links or resources; a link can use rel=noreferrer. Prefer a consistent site policy where possible, then document any page or element exception. Check what the hosting layer, application framework and CDN actually return: a header configured in application code can be absent on a cached page, an error page or a static landing page. A page-level exception may also be defeated by a later change to a shared template. Inspect the final response received by a browser rather than trusting a configuration file. For sensitive account or payment-related pages, decide whether no-referrer or same-origin better fits the real flow, and test external handoffs with the provider. The policy is a privacy control, not access control: it does not prove a destination can be trusted, prevent tracking through other fields, hide a URL the customer copies, or replace authorization on an order endpoint. In particular, do not put credentials or one-time secrets in URLs on the assumption that a referrer setting will protect them. Such values need their own design review and expiry rules.
Verify requests, not just the header
Create test URLs with harmless marker values, never real customer data. Visit the page over HTTPS and inspect the browser network panel while following an internal link, an external HTTPS link and any external image or script. At the receiving test endpoint, observe whether the Referer is absent, an origin, or a full URL. Repeat from a sensitive page and from a normal public page. Confirm what happens on the final destination after a redirect, because the real user journey may have several hops. Test the languages and mobile layout if they use different templates. Compare the observed requests with the documented policy table; a header being present is not enough if another page or embedded resource escapes the intended scope. If an external provider says a full path is required, identify the exact integration feature and obtain a safe alternative before relaxing the policy. Record the expected result for each test and retain only synthetic URLs in screenshots. After release, watch for newly added third-party widgets and links in editorial pages, and recheck the policy when payment, support or analytics integrations change. That lightweight review protects the decision over time without claiming that one successful browser test proves every browser or every future page.
Make the decision reviewable
A practical handoff has four parts: a list of pages with potentially revealing URLs, the selected policy and any exceptions, a small matrix of expected outgoing requests, and a named owner for later changes. The first owner may be a developer, but marketing and support need to understand why a referral report can change when a stricter policy is deployed. If attribution is important, define which aggregate source information is enough and avoid using a customer's account or enquiry path as a reporting input. Treat unexpected full-URL referrers as defects to investigate, not as useful new analytics. If the business has no justified need for referrers on a sensitive workflow, no-referrer is a clear option. If it relies on same-origin diagnostics and only needs domain-level external attribution, strict-origin-when-cross-origin may be a defensible baseline after testing. Choose explicitly, write down the trade-off, and retest the request traces after each material template or integration change. The reader-facing result is simple: customers can follow an ordinary link without the site casually disclosing the detailed page they were viewing.
Know which safeguards are separate
A final review should distinguish the page's referrer setting from controls that solve different problems. Referrer-Policy governs a browser's outgoing referrer information; it does not limit what a third-party script already running on the page can read within its granted context, nor does it turn an untrusted destination into a safe one. A sensitive account page may therefore need both a restrictive policy and a separate review of embedded scripts and outbound links. Likewise, a destination's own query parameters are visible to that destination by design, so the business must decide what information to include there. If a payment or delivery partner requires a return address, test the exact handoff and callback rather than relaxing a whole site's policy on assumption. Keep a short change record identifying which page, which partner, the observed request and the approved exception. This makes a later investigation possible when a provider changes its integration or a new campaign template appears. The best policy is the one that meets a documented need with the least disclosure verified in real requests.
Before you proceed
- Inventory customer pages with query strings and external requests.
- Choose a documented policy for public and sensitive flows.
- Use synthetic URLs to verify actual outgoing Referer headers.
