Besides the Referrer-Policy response header, how can a document set or override a referrer policy per element?
answer
- a policy has more than one delivery point
- an element attribute beats the document policy
- meta applies from where it parses
- rel noreferrer blanks one navigation
- a redirect response can change it mid-chain
basics
~20 sA document can carry a meta element whose name is referrer, and the a, area, img, iframe, link and script elements accept a referrerpolicy content attribute that governs that one element's request. A link's rel keyword noreferrer suppresses the value for that navigation.
solid answer
~50 sThe response header sets the policy for the whole document, but it is not the only delivery point. A `meta` element whose name is `referrer` sets the document policy from the point it is parsed, so requests already started keep whatever was in force before. The `referrerpolicy` content attribute on `a`, `area`, `img`, `iframe`, `link` and `script` overrides the document policy for that element's own request, and it can loosen as well as tighten — any token is accepted. On a link, the `noreferrer` keyword in `rel` suppresses the value for that navigation. Two more points get missed: the policy is re-evaluated along a redirect chain, so a redirect response carrying its own `Referrer-Policy` governs the requests that follow it; and a document created from an inherited context takes its creator's referrer policy rather than starting with the default.
code
html · 9 lines<meta name="referrer" content="strict-origin-when-cross-origin">
<img src="https://tiles.example.net/9/271/168.png"
referrerpolicy="no-referrer"
alt="Parcel location">
<a href="https://assessor.example.net/rules" rel="noreferrer">Assessment rules</a>
<script src="/assets/appeal-form.js"></script>go deeper
Recall that the response header is the usual way to set a referrer policy, and that individual elements can carry their own setting for one request.
Explain precedence: element attribute over document policy over default, and why a policy declared in markup only covers what the parser has not already requested.
Show that a document-level policy is not a guarantee about every request from that document — a single element attribute, or a redirect hop, can change the value that leaves.
Decide where a policy is owned across an estate: a header set at one place for everything, versus markup that each team can override element by element.
## Four places a referrer policy comes from On a page of any size the policy in force for a given request is rarely 'the one in the response header'. There are four delivery points, and they layer: 1. **The `Referrer-Policy` response header**, which sets the document's policy for everything the document does. 2. **A `meta` element whose name is `referrer`**, which sets the document policy as the parser reaches it. 3. **The `referrerpolicy` content attribute** on `a`, `area`, `img`, `iframe`, `link` and `script`, which governs that element's own request only. 4. **The `noreferrer` keyword in a link's `rel` attribute**, which suppresses the value for that navigation. The narrower setting wins for the request it applies to: an element's attribute beats the document policy, and the document policy beats the default. ## The per-element attribute cuts both ways It is tempting to describe `referrerpolicy` as a way to tighten a single element, and that is the common use — the analytics beacon or the third-party map tile on an appeal portal gets `referrerpolicy="no-referrer"` while the rest of the document keeps the default. But the attribute accepts any token, including the permissive ones, so it is equally a way to hand one specific destination more than the document policy allows. That is a real review point: a document-level policy is not a guarantee about every outgoing request from that document. ## Order matters for the meta element Because a `meta` element takes effect when the parser reaches it, anything the browser has already started fetching used the policy that was in force at the time. A policy declared halfway down the document does not retroactively change a request that has already gone out. That is one practical argument for the response header: it applies to the document as a whole and cannot be raced by the parser. ## Redirects re-evaluate A redirect chain is not governed by one frozen policy. The referrer for the next hop is computed from the URL that redirected, and if the redirect response itself carries a `Referrer-Policy`, that policy applies onward from that hop. This is why a chain that ends somewhere unexpected can send a different value than the one you predicted by reading only the first response, and why a policy applied at one hop of a chain does not describe the whole chain. ## Inheritance A document that is created rather than fetched — one created from a blank or generated context — does not start with the default policy. It takes the referrer policy of the context that created it, carried along with the rest of that context's policy state. The practical consequence is that a generated frame inside a page with a strict policy keeps that strict policy; you do not have to re-declare it, and you cannot assume it has been reset. ## A worked layout On the appeal portal: - the response header sets `strict-origin-when-cross-origin`, so the parcel identifier and the grounds in the query never leave your own origin; - the embedded map tile carries `referrerpolicy="no-referrer"`, because the tile host does not even need to know which site asked; - the web font and the analytics beacon are left on the document policy, so each host learns the origin and nothing more; - an outbound link to an assessment-rules page carries `rel="noreferrer"`. That is four different outcomes on one page, and only one of them is the header. ## What this is not This is all about **what the browser sends**. The separate question of what some recipient then does with the value — whether any server should treat it as evidence of anything — is a different subject with different rules, and mixing the two is how candidates end up defending a policy decision on the wrong grounds. Keep the answer on the sending side: which policy is in force for which request, and which of the four delivery points decided it.
- A request is redirected and the redirect response carries its own `Referrer-Policy`. Which policy governs the next request?The one from the redirect response, applied from that hop onward; the referrer for that next request is computed from the URL that redirected. A policy read off the first response therefore does not describe the whole chain, which is why a value can arrive that the original document's policy would never have produced.
- Which elements accept the `referrerpolicy` content attribute?`a`, `area`, `img`, `iframe`, `link` and `script`. It governs that element's own request and overrides the document policy for it, in either direction — it can be more permissive than the document policy as well as more restrictive.
- Does a `meta` element whose name is `referrer` affect requests the browser has already started?No. It takes effect when the parser reaches it, so anything already requested used the policy in force at that moment. If you need the policy to cover the whole document without depending on parse order, send it as the response header.
saying these in an interview costs you the question
- Thinks only the response header can set a referrer policy.
- Says a per-element attribute can only tighten, never loosen.
- Assumes a meta referrer governs requests already sent.
- Believes one policy is frozen for a whole redirect chain.
- Treats the rel noreferrer keyword as an attribute on any element.