Your server refuses any WebSocket upgrade whose Origin field is not allowlisted, yet a scripted non-browser client connects freely. Why?

## Who fills the field in When a browser opens a WebSocket, it composes the handshake itself: the `GET` line, `Host`, `Upgrade: websocket`, `Connection: Upgrade`, `Sec-WebSocket-Key`, `Sec-WebSocket-Version: 13`, and — because `RFC 6455` requires it of browser clients — `Origin`, set to the origin of the document that asked for the socket. The page supplies a URL and nothing else. It cannot reach into the handshake and change `Origin`, which is precisely why a server can draw a conclusion from it. A client that is not a browser has no such constraint. It assembles the request bytes itself, so `Origin` is just another line it can type, and the specification treats it as optional for non-browser clients. A script, a load generator, a service-to-service client or someone at a terminal will send `Origin: https://console.example` as easily as omitting it. Nothing on the wire distinguishes that request from the real console's. ## Cross-site defence versus authentication The distinction an interviewer is fishing for is what the check actually removes from the threat model: - **What it stops:** a page the victim's browser loads using the victim's **ambient** credentials — the cookie already in the browser, attached automatically. The attacker never sees that cookie; it is spent on their behalf. Refusing the handshake on `Origin` takes that away, because the attacker cannot make the victim's browser lie about where the page came from. - **What it does not stop:** anyone holding a credential, or probing without one, from a client of their own. They set the field and proceed. If your endpoint is reachable and your credential check is weak, the allowlist bought you nothing against them. | threat | blocked by Origin validation? | why | |---|---|---| | attacker's page in the victim's browser | yes | the browser sets the field, the page cannot | | a stolen cookie replayed from a script | no | the script types any origin it likes | | an unauthenticated probe from a terminal | no | same — the field is free text to it | | a network attacker reading frames | no | that is what transport encryption is for | ## Two decisions this forces **What an absent field means.** Because non-browser clients may omit `Origin` entirely, some share of legitimate traffic on many endpoints arrives without it. Default-allowing a missing field turns the whole check into a single line an attacker deletes. Default-denying it breaks every legitimate non-browser client. Neither is automatically right — the answer is per endpoint, and it should be written down: an operator-console socket can require the field and refuse without it, while a machine-to-machine endpoint should not consult it at all and should lean entirely on its credential check. **Where the allowlist lives.** One list, compared whole-string, applied in the handshake path. Origins tend to multiply — a staging console, a preview host, a second municipal department — and the moment the list is maintained in several places one copy grows a wildcard. An allowlist with a wildcard entry is, for this purpose, no allowlist at all. ## Why candidates get this backwards The field is named after a security concept and appears in a security-shaped position, so it is read as an identity claim. It is closer to a *provenance hint that only one kind of client is bound to tell the truth about*. The honest summary is two sentences long, and both halves are needed: 1. `Origin` validation is the defence against a socket opened by a page the user did not intend to grant access to; 2. it says nothing about who the client is, and every non-browser client can forge it. A useful phrasing to keep in your pocket: the field answers the question *which page asked for this socket*, and it answers it honestly only when a browser is the one filling it in. It never answers *who is on the other end*, and no amount of allowlist tightening turns the first question into the second. On the occupancy board, that means the server keeps both gates. The `Origin` allowlist refuses a handshake from anywhere but the operator console, so a stray page the operator visits cannot ride their session. The credential check runs regardless, so the field-less connection from the city's own reporting job is allowed or refused on what it presents, not on a string it could have typed. Remove either gate and one whole class of caller walks in.