How do clients smuggle a bearer token through Sec-WebSocket-Protocol on a WebSocket upgrade, and what must the server echo?

## Why anyone does this A browser page has two inputs to the upgrade: the URL and the subprotocol list. The URL is the request target, and request targets are logged everywhere. The subprotocol list becomes a request field, and request fields are logged far less often — most default access-log formats record the method, the target, the status and the size, and nothing else. So the trick is to offer two values where one is real: ```http Sec-WebSocket-Protocol: cabinet.v1, bearer.kQ7mS1xbN0 ``` The first is the application subprotocol the connection will actually speak. The second is not a subprotocol at all — it is a credential wearing a subprotocol's clothes. The server splits the list, recognises the prefixed value as a credential, authenticates it, and proceeds. ## What the server owes in reply Subprotocol negotiation is a selection: the client offers, the server picks **at most one** and names it in its `Sec-WebSocket-Protocol` response field, and a server must not name a value the client did not offer. Two consequences fall out of that, and they are the specific cost of this abuse: - **The server must echo exactly one value, and it must be the real subprotocol name.** Returning both is not a selection. Returning the token is worse: it writes the credential into the response, where a response-logging intermediary or a stored error page can capture it, and it tells the client to speak a subprotocol that does not exist. - **The server must still complete negotiation correctly for the real value.** The client offered `cabinet.v1` because it intends to speak it; the credential value must be stripped before the selection logic runs, or the server ends up choosing between a protocol and a password. The negotiation rule itself — what a selected name means, how extensions differ, what a client does when nothing is selected — belongs to the leaf that owns subprotocols. What belongs here is that **using the field as a credential channel puts an obligation on the response that an ordinary negotiation does not have.** ## What it buys and what it does not | | Token in the query string | Token as a subprotocol value | |---|---|---| | Recorded in default access logs | yes, as part of the request target | rarely: request fields are usually not logged | | In browser history | yes | no | | Travels in a copied URL | yes | no | | Abuses a mechanism | no | yes: a negotiation field carries a credential | | Server-side complexity | parse a query parameter | split a list, strip a value, select correctly | | Expires any faster | no | no | It is a genuine improvement on the leak surface and **no improvement at all on lifetime**. A long-lived token smuggled through the subprotocol list is still a long-lived token; if it does end up in a field-logging intermediary or a debug capture, it is just as useful to whoever finds it. Pairing the technique with a short-lived, single-use value gets you both properties. ## Where it is the wrong answer - **On a non-browser client**, always. A service can set `Authorization`; there is no reason to overload a negotiation field. - **When the value is long-lived.** The technique moves where a credential is written down, not how long it is worth having. - **When you do not control the server.** This only works if the server is written to expect it, because the extra value is meaningless to anything else and a strict implementation may simply select nothing. ## What an interviewer is listening for That you can explain *why* the field is attractive — it is one of exactly two things a page controls, and it is not the request target — and that you know the echo obligation. Candidates who have only read about the trick describe the request and stop; the response half is the part that has a rule attached to it.