Referrer-Policy and link hygiene
Why it matters Every time a visitor clicks a link or your page loads a file from elsewhere, the browser may tell the other side which of your pages they came from. If your URLs hold search terms, order numbers or reset tokens, that is your visitors' business leaking out. A few lines of policy and some care with URLs stop it.
A URL is like the outside of an envelope. The post office, the sorting room and the person who receives it can all read it. Anything private belongs inside the letter, not on the envelope.
Referer header: a request header (spelled with one "r" in the middle, a famous old typo) that tells a server the address of the page that sent the visitor or loaded the file. You met it in Leg 1 from the visitor's side.
Referrer-Policy: a response header (or a <meta> tag, or an attribute on a single link) that tells the browser how much of your page's address to put in the Referer header.
The values that matter
| Policy | To your own site | To other sites |
|---|---|---|
no-referrer | nothing | nothing |
same-origin | full URL | nothing |
strict-origin | origin only | origin only (nothing from HTTPS to HTTP) |
strict-origin-when-cross-origin | full URL | origin only (nothing from HTTPS to HTTP) |
unsafe-url | full URL | full URL, always. Avoid. |
The origin is just the scheme and host, such as https://shopd.example, without the path or query. Modern browsers use strict-origin-when-cross-origin by default when a site sets nothing, and some trim cross-site referrers further (checked October 2026). Set it explicitly anyway, so an old browser or a forgotten unsafe-url somewhere cannot undo it, and choose same-origin or no-referrer on sensitive pages.
Referrer-Policy: strict-origin-when-cross-originIn Django this is one setting, SECURE_REFERRER_POLICY. Its default is already the stricter "same-origin"; set "strict-origin-when-cross-origin" only if partner sites need to see where visitors came from (checked October 2026).
Link hygiene: what not to put in a URL
- Personal data. No email addresses, names or phone numbers in query strings, such as
/welcome?email=sam@mail.example. They end up in server logs, browser history, analytics and, under a weak policy, other sites. - Sensitive searches. A pharmacy URL like
/search?q=pregnancy+testsays a lot. Send sensitive searches with a POST form, or at least keep third-party scripts off the results page. - Secrets. Password-reset and login links carry tokens. Make them single-use and short-lived, and keep third-party scripts off the page they land on, because any script on the page can read its address.
Outgoing links
- Do not add tracking parameters such as
utm_sourceto links pointing at other sites, and do not send outgoing clicks through a redirect on your server just to count them. - For a link you do not want to carry any referrer, add
rel="noreferrer". rel="noopener"stops the opened page from controlling your tab throughwindow.opener. Modern browsers already apply it totarget="_blank"links (checked October 2026), but writing it costs nothing.
<a href="https://partner.example/" rel="noopener noreferrer" target="_blank">Our partner</a>A common misconception: "HTTPS hides the URL". HTTPS hides it from the network in between, but the browser itself still puts it in history and, depending on the policy, in the Referer it sends. Scripts on the page can always read it.
Try it On a site of yours, open DevTools, click an outgoing link with the Network tab open (tick "Preserve log"), and select the new request. Under Request Headers, look at Referer: is it the full path or only the origin?
Recap
- Set
Referrer-Policy: strict-origin-when-cross-originor stricter, and stricter still on sensitive pages. - Keep personal data, sensitive searches and secrets out of URLs.
- Do not decorate or redirect outgoing links; use
rel="noopener noreferrer"where it fits.
This lesson is locked
Lessons open one at a time. Finish the previous lesson to unlock this one.