The Origin header does arrive. RFC 6455 has the browser attach it to the handshake, and no CORS restriction acts on what it says [2]. CORS governs XMLHttpRequest and fetch; the `WebSocket()` constructor sits outside both, with no preflight to fail and no `Access-Control-Allow-Origin` to check [3]. So the browser hands your server the one piece of evidence that would settle the question, and whether anything compares it against an allowlist is a property of your handler, not of the protocol.
Express with the `ws` library exposes a `verifyClient` callback, but nothing requires it, and the default accepts any Origin [6]. The hook exists, and calling it is left to the developer. FastAPI and Starlette have no built-in Origin validation for WebSocket routes at all, and their `CORSMiddleware` applies to HTTP routes only, so the check has to be manual code in the route handler [9].
Socket.io is the one entry with a version boundary. Releases before 2.4.0 accepted all origins by default, tracked as CVE-2020-28481, and 2.4.0 disabled CORS by default, though what that default governs is HTTP responses [10]. The writeup's account breaks off there [10], so it does not establish whether the handshake itself is validated. Counting Socket.io as fixed means reading its release notes closely, since the CVE title covers only part of the picture.
What the gap has actually produced is on record. CVE-2023-0957 hit Gitpod before release-2022.11.2.16, where the JSONRPC API ran over WebSocket with cookie authentication and no Origin check; Snyk's team combined the hijack with a SameSite subdomain bypass to take over a workspace, including code execution [15]. CVE-2024-51775 covered Apache Zeppelin 0.11.1 at CVSS 7.5, where remote network access with no authentication and no user interaction was enough to read paragraph content out of authenticated sessions [16]. The dev.to writeup's diagnosis of the pattern is organisational: cookie authentication works on the HTTP routes and becomes the assumed boundary, then a socket gets added later, often by a different team, without mirroring the CSRF controls already there [17].
For that framework survey to describe your service, two things have to hold. Your handshake has to authenticate from cookies the browser will attach for a page you do not control [2], and your clients have to be browsers, since browser-set Origin is the whole basis of the check [2]. A socket that takes a bearer token in its first application frame fails for reasons unrelated to Origin validation.
Christian Schneider formalised the attack in 2013 under CWE-1385, and James Kettle's PortSwigger material is the canonical public teaching reference [11][12]. The Zeppelin CVE landed eleven years after that [18]. Gitpod shipped its fix within 24 hours of disclosure [15], which is the turnaround typical of an allowlist fix rather than a redesign.
