Cross-Site WebSocket Hijacking Persists as Major Frameworks Skip Origin Checks by Default

A post on dev.to argues that Cross-Site WebSocket Hijacking (CSWSH) is still a practical threat more than a decade after it was first described, because the dominant server frameworks continue to ship WebSocket support without Origin validation enabled. According to the write-up, four of the five most widely used frameworks accept connections from any origin by default, which means a single page controlled by an attacker can convert a victim's authenticated session into a channel the attacker can both read and write.

How the attack works

The dev.to author frames the root cause as protocol design rather than misconfiguration. The WebSocket handshake defined in RFC 6455 is an HTTP Upgrade request, and browsers issue it cross-origin without a CORS preflight or an Access-Control-Allow-Origin check, because CORS governs XMLHttpRequest and fetch rather than the WebSocket constructor. Session cookies travel with the request.

That makes CSWSH more damaging than classic CSRF. With CSRF the attacker can fire a request but cannot see the response; with CSWSH, once the hijacked connection is established, the attacker's page can read everything the server sends and inject its own frames under the victim's identity — a lasting, two-way channel tied to a live session, with no XSS or phishing required. Christian Schneider formalised the attack in 2013; it is tracked as CWE-1385, and the author points to James Kettle's material at PortSwigger's Web Security Academy as the standard reference on the mechanism.

Three incidents that made it real

The post cites three CVEs as evidence that the gap has real consequences:

• LogRhythm Platform Manager 7.4.9. CVE-2020-25095 let WebSocket connections in without Origin checks, and when chained with command injection in CVE-2020-25094 in the Smart Response agent interface running as LocalSystem, gave unauthenticated remote code execution against any logged-in victim whose browser loaded the attacker's page.
• Gitpod before release-2022.11.2.16. CVE-2023-0957 affected a JSONRPC API served over WebSocket with cookie authentication and no Origin check; Snyk's team combined it with a SameSite subdomain bypass to take over workspaces entirely, including code execution. The fix landed within 24 hours of disclosure.
• Apache Zeppelin 0.11.1. CVE-2024-51775, scored 7.5 on CVSS, exposed paragraph content from authenticated sessions to anyone with network access, with no authentication and no user interaction.

The common thread, per the author, is that cookie authentication works on existing HTTP routes and quietly becomes the assumed security boundary; WebSocket endpoints added later, often by a different team, never inherit the CSRF controls.

Vulnerable out of the box

• Express with the ws library: the verifyClient callback exists but is optional, and the default accepts any origin. The upgrade also bypasses the Express middleware stack, so validation must be written explicitly in the upgrade handler.
• Django Channels: the project documents the cross-site risk, but the OriginValidator and AllowedHostsOriginValidator middlewares ship as optional ASGI wrappers and are not enabled in the default setup.
• FastAPI and Starlette: there is no built-in Origin validation for WebSocket routes, and CORSMiddleware covers HTTP routes only, leaving manual checks inside each route handler.
• Socket.io: versions before 2.4.0 accepted all origins (CVE-2020-28481). Version 2.4.0 disabled CORS by default, but per the post that setting governs HTTP responses from the polling transport, so explicit cors configuration is still needed for the WebSocket transport.
• Gorilla WebSocket for Go: the library defaults to comparing only the Host header, and the widely copy-pasted workaround of overriding CheckOrigin with a function that always returns true regularly ships to production.

Detecting and closing the gap

Detection sits at the upgrade boundary. Legitimate upgrades carry an Origin matching the application domain plus a valid session cookie, while a hijacking attempt carries an attacker-controlled Origin alongside a valid cookie — a pairing that never occurs in normal use, according to the author. Filtering upgrades where the Origin falls outside an allowlist and the Cookie header is non-empty yields essentially no false positives, and the session ID in that Cookie header identifies the targeted account. Requests with no Origin header, as sent by curl or server-to-server clients, should be treated as untrusted rather than accepted silently.

For defence, the post prescribes three layers used together: a server-side Origin allowlist that rejects mismatches and missing values; a short-lived CSRF token passed as a query parameter on the upgrade URL and validated before the handshake completes; and SameSite cookies — Strict preferred, with Lax effective in current browsers because WebSocket handshakes are not top-level navigation requests, a finding the author attributes to Include Security research from April 2025, while SameSite=None remains fully exploitable. The post also relays OWASP's advice to move WebSockets off cookie authentication in favour of header-based tokens.

Why it matters

This is a defaults problem in mainstream tooling, so the exposure is broad: any cookie-authenticated application that added a WebSocket endpoint inherits it silently, and the failure mode is worse than CSRF because the attacker gets a read-write window into an authenticated session rather than a blind request. The offsetting good news is that the detection signal is unambiguous and the fix is well understood, which makes the persistence of vulnerable defaults twelve years after the attack class was documented largely a matter of engineering attention.