skip to content

What does the `Referrer-Policy` response header control, and which URL parts does a browser always remove?

level: juniorimportance: must knowfreq 60%

answer

  1. controls what the next request reveals
  2. policy on the response, value on the request
  3. Referer is spelled with one r
  4. credentials and fragment go in every case
  5. an absent header still means the default

basics

~20 s

Referrer-Policy is a response header that tells a conforming browser how much of the current page's URL to put in the Referer request header on outgoing requests. Username, password and fragment are removed in every case.

solid answer

~40 s

`Referrer-Policy` is a **response** header: the server sends it with a document, and it governs the value of the `Referer` **request** header — one `r`, frozen as a misspelling in HTTP — that the browser attaches to requests the document makes. Before any token is applied the browser removes a username and password embedded in the URL and drops the fragment; a URL whose scheme is not an HTTP(S) scheme yields no referrer at all. The token then decides whether what remains travels whole, is cut down to the origin with no path and no query, or is suppressed. None of this changes the URL being requested — only what the destination learns about where the request came from. An absent header is not an absent policy: current browsers apply `strict-origin-when-cross-origin` by default.

code

http · 7 lines
http
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Referrer-Policy: strict-origin-when-cross-origin

GET /tiles/9/271/168.png HTTP/1.1
Host: tiles.example.net
Referer: https://appeals.example.org/

go deeper

for a junior

Recall the direction: the policy arrives on a response, and the value leaves on the next request as Referer. Know that credentials in the URL and the fragment never travel.

for a middle

Explain that the policy only reduces the value — whole URL, origin only, or nothing — and that an unset header still leaves the default policy in force.

for a senior

Show where the leak actually bites: a path and query that are themselves sensitive, handed to embedded third parties, and the outcome you pick so the origin still travels.

for a principal

Frame it as a data-exposure default set once for a whole estate: what every property emits outbound, and which reporting quietly depends on that value still being there.

## Two headers, one letter apart `Referrer-Policy` is a **response** header field. A server sends it alongside a document, and it establishes that document's **referrer policy** — a value the browser keeps with the document and consults every time the document causes a request. `Referer` is a **request** header field, spelled with a single `r` because the misspelling was frozen into HTTP decades ago; the specification marks it `[sic]` (RFC 9110 Section 10.1.3). It carries a URL describing where the request came from. The relationship is one-way and easy to state: 1. The response declares the policy. 2. The browser reduces the current document's URL according to that policy. 3. The reduced value, if any, leaves as `Referer` on the next request. Nothing in that chain changes the URL being requested. A referrer policy does not hide a page from the server hosting it; it controls only what **other** endpoints learn about where a request originated. ## What is removed before any token is consulted Building the value starts with a fixed reduction of the document's URL, and it happens whatever the policy says: - a **username** and **password** embedded in the URL are removed; - the **fragment** — everything from `#` onward — is removed; - if the URL's scheme is not an HTTP(S) scheme, there is no referrer at all. Only then does the policy token choose between three outcomes: send the reduced URL whole, apply the **origin-only flag** — which additionally empties the path and drops the query, leaving `scheme://host/` — or send nothing. One further reduction sits on top of all of them: if the serialization of the value would exceed **4096** characters, the browser falls back to the origin regardless of the policy in force. ## Why the origin-only outcome is the whole point Consider a tax-assessment appeal portal whose URLs are themselves the sensitive thing: `https://appeals.example.org/appeals/2291?parcel=41-207-018&grounds=valuation` The path identifies an appeal, and the query names a parcel and the grounds being argued. That page embeds a third-party map tile, a web font from another host and an analytics beacon. Every one of those embedded requests is an opportunity to hand the whole URL — parcel number, grounds and all — to an operator who has no business with it, inside a header nobody ever looks at. The origin-only outcome closes it: the map host learns that a request came from `https://appeals.example.org/` and learns nothing else. ## Where a policy can come from The response header is the usual delivery point, but not the only one: - the response header, which applies to the document it arrives with; - a `meta` element whose name is `referrer`, applied as the document parses; - a `referrerpolicy` content attribute on an individual element, which governs that element's own request; - `rel` with the `noreferrer` keyword on a link, which sends nothing for that navigation. ## An absent header is not an absent policy The most common wrong answer here is that a response with no `Referrer-Policy` sends everything. Current browsers apply **`strict-origin-when-cross-origin`** as the default, so an unset header already means: the full URL to your own origin, the origin only to a different origin, and nothing at all on a request from an HTTPS page to a plain HTTP destination. An explicitly empty header value is also valid and means *no policy stated*, which falls back the same way — to an inherited policy where one exists, otherwise to the default. This cuts both ways. A site that never set the header is not leaking full URLs to third parties; and a team that adds `Referrer-Policy: unsafe-url` to satisfy a reporting integration has made things strictly worse than doing nothing. ## What HTTP itself requires, and how strongly The policy mechanism sits on top of two rules in HTTP's own definition of `Referer`, and their strengths differ. Promoting one to the other teaches a false certainty: | rule | strength | |---|---| | Do not send `Referer` in an unsecured request when the referring resource was accessed securely | **MUST NOT** | | Suppress the value on cross-origin requests from a securely accessed resource | **SHOULD NOT** send | The plaintext case is a hard prohibition; the general cross-origin case is a recommendation — which is exactly why an explicit policy is worth sending rather than trusting to good behaviour. ## How to answer it out loud State the direction first (a response header sets it, a request header carries the result), then the three outcomes, then the default. If you have one more sentence, spend it on the fixed removal of credentials and fragment: it is the detail that shows you have read the algorithm rather than a hardening checklist.

  • A response sends no `Referrer-Policy` at all — what policy is in force?
    The default, `strict-origin-when-cross-origin`. A same-origin request carries the full URL, a cross-origin request to another HTTPS destination carries only the origin, and a request from an HTTPS page to a plain HTTP destination carries nothing. An explicitly empty header value means no policy stated and falls back the same way.
  • Which of the two spellings goes on which message?
    `Referrer-Policy`, with two `r`s, is the response header that sets the policy. `Referer`, with one `r`, is the request header that carries the resulting value, and the specification marks that spelling `[sic]`. A candidate who says 'the referrer header' has named neither of them.
  • What do you give up by setting `no-referrer` everywhere?
    Every outgoing request loses its source, so outbound attribution and any per-source reporting on the pages you link to go blank, and anything downstream that consumed the value stops seeing it. A policy that keeps the origin cross-origin while dropping path and query closes the leak without blanking the value.

A referrer policy is the rule for how much of the return address you write on an outgoing envelope. The letter arrives either way; what changes is how much the recipient learns about where it came from.

saying these in an interview costs you the question

  • Calls Referrer-Policy a request header the browser sends.
  • Says an unset header means no policy, so full URLs leak.
  • Spells the request header with two r's.
  • Thinks the fragment travels unless a policy removes it.
  • Claims the header hides the URL from the site being requested.