Why does the departures host see an `Origin` header on a request the browser sent to that same host, and what does its presence prove?

An arrivals board is embedded on many host pages and calls one departures host for data, but the board's own administrative screens post back to the host that served them. Those same-host posts show up in the request log carrying an `Origin` field, and the first reaction is that something is misrouted. Nothing is misrouted. The rule for attaching the header has two independent triggers, and only one of them is about crossing an origin boundary. ## The two triggers 1. **Response tainting is `"cors"`.** When a request is made in a mode where the response may be handed to script only under an explicit grant, the header goes on so the receiving host can decide whether to grant. This is the trigger everyone knows, and it is the one that is genuinely about direction. 2. **The method is neither `GET` nor `HEAD`.** In the ordinary case, a request with any other method carries the header no matter where it is going — including straight back to the host that served the page. The second trigger is not an accident of implementation. `GET` and `HEAD` are the methods a browser will emit from ordinary markup without any script at all, at enormous volume; stamping every one of them would attach an identity field to essentially all browsing traffic. Methods that change state are both rarer and the ones a receiving host most wants to be able to attribute, so those get the field unconditionally. ```http POST /admin/board-messages HTTP/1.1 Host: board.example.org Origin: https://board.example.org Content-Type: application/x-www-form-urlencoded ``` Here `Host` and `Origin` name the same host. This request never crossed an origin boundary, and it still carries the field. ## What follows for the receiving host | Observation | What it actually licenses | |---|---| | The field is present | Either the request was made in a mode needing a grant, **or** its method was not `GET`/`HEAD` — you cannot tell which from presence alone | | The field is absent | Possibly a same-host `GET` or `HEAD`, possibly a client that is not a browser at all | | The field equals your own origin | The initiating context was your own origin, as the browser serialized it | | The field is some other origin | The initiating context was that one, as the browser serialized it | The first two rows are the ones that get answered wrongly in interviews. "The header is there, so this is cross-origin" is false because of trigger two. "The header is missing, so this is same-origin" is false because safe methods never carry it — and because the header is stamped by a browser, so a request that no browser made carries whatever its sender decided to carry, including nothing. ## Reading it correctly The information is in the **value**, not in the field's existence: - Compare the arriving value against the receiving host's own serialized origin. Equal means the initiating context was the same origin; different means it was a different one. - Remember that the comparison is over bytes, so the receiving host's own origin has to be written the same canonical way — scheme, host, non-default port only. - Treat a *missing* field as an absence of information rather than as evidence, because two very different situations produce it. ## Why this trips people up The mental model most engineers build is "the browser adds this header when it is calling someone else", which is exactly half the rule and the half that produces confident wrong answers. It also explains a common report from operators: a log filter written as "requests carrying an Origin field" intended to isolate embedded-board traffic ends up including every administrative post made from the host's own pages, because those posts satisfy trigger two. The repair is one sentence long: **presence is a fact about the request's method and mode; direction is a fact about the value.** Once that is separated, the same-host `POST` stops looking like a bug and the missing field on a same-host `GET` stops looking like one either.