What does a WebSocket upgrade authenticated by a session cookie get for free, and what risk does that create?

## Why the cookie route exists at all A page cannot put a credential in a field on the WebSocket upgrade, because it never builds that request. It can put one in the URL, or smuggle one into the subprotocol list, or redeem a ticket — all of which are code the page has to write and a credential the page has to hold. A **cookie** is the one credential that needs neither: the upgrade is an ordinary HTTP request to an origin, so the browser attaches the cookies scoped to that origin exactly as it would on any other request to it. For a console that already authenticates its ordinary requests with a session cookie, this is free and consistent: the socket is authorized by the same session as the rest of the application, with no second credential to store, refresh or leak. ## The same automatic attachment is the risk The browser attaches that cookie based on where the request is **going**, not on who asked for it. A page on an unrelated site can open a socket to your endpoint, and if the cookie's attributes permit it, the browser will attach the session cookie to that upgrade too. The attacker's page never sees the cookie — but it does not need to. What it gets is an **authenticated, full-duplex connection** it can write commands into and read responses from, which is strictly worse than a one-shot cross-site request: there is no response-reading restriction once frames are flowing. This is the shape that makes cookie-authenticated sockets a standing review item. The two things that stop it: - **The cookie's own attributes.** `SameSite` decides whether the cookie travels on a cross-site request at all, and a session cookie that does not travel cross-site cannot be borrowed this way. Treat this as the default that must hold, not as the whole defence — it is a per-client behaviour and one attribute away from being switched off. - **Deciding who started the upgrade.** The upgrade carries an `Origin` request field naming the page that initiated it, and a server can refuse upgrades whose origin it does not recognise. The validation itself — what to compare, what to do about a missing field, how it interacts with wss termination — belongs to the leaf that owns origin, TLS and intermediaries; what belongs here is knowing that **choosing the cookie route is what makes that check load-bearing.** ## Cookie versus token, side by side | | Cookie on the upgrade | Token the page holds | |---|---|---| | Attached by | the browser, automatically | the page, explicitly | | Page code needed | none | store, attach, refresh | | Cross-site exposure | high — this is the whole hazard | none: nothing attaches it for you | | Where it can leak | nowhere new; it is not in the URL | the URL, and everything that logs URLs | | Works for non-browser clients | rarely, and awkwardly | naturally | | What must be checked | who started the upgrade | the token itself | The two columns fail in opposite directions, which is the point. The cookie cannot leak into a log because it is never in the request target — but it is attached for anyone. A token cannot be attached for anyone — but the only place a page can put it is somewhere that gets written down. ## What this looks like in practice On a console whose users are already signed in with a session cookie, the sequence is: 1. The page opens the socket with nothing but a URL. 2. The browser attaches the session cookie, subject to its attributes. 3. The server reads the cookie, resolves the session, and decides whether to complete the handshake. 4. Before it does, it checks the `Origin` field and refuses the upgrade if the page that started it is not one of yours. 5. The principal from that session is attached to the connection and every frame is attributed to it. Step 4 is the one teams skip, because steps 1 to 3 work perfectly without it and nothing visibly fails. ## The honest limitation A cookie is a **browser** credential. A background service opening the same endpoint has no cookie store and no reason to have one; making it fabricate a cookie to satisfy your socket endpoint is a smell. If the same endpoint serves both, expect to accept two credential routes and to say plainly which clients use which — a cookie plus origin check for pages, a request field for services.