WebSocket Security Fundamentals
What Are WebSockets?
WebSockets power the real-time layer of the modern web. Every time you see a chat message appear without refreshing the page, a stock price update in a trading platform, or a live notification in a project management tool, there is almost certainly a WebSocket connection running underneath. Unlike HTTP — where the browser sends a request and waits for a response — a WebSocket connection stays open indefinitely, allowing both sides to send messages at any moment.
The Upgrade Handshake
A WebSocket connection begins as a standard HTTP request. The browser sends an HTTP/1.1 GET request with a special header — Upgrade: websocket — asking the server to switch protocols. The server responds with HTTP 101 Switching Protocols, and from that point forward the connection becomes a persistent binary stream.
There is one critically important detail about this handshake: the browser automatically sends all cookies for the target domain along with the upgrade request. This is the same behaviour as any other HTTP request — and it is the behaviour that attackers exploit.
Cross-Site WebSocket Hijacking (CSWSH)
Imagine a user is logged in to chat.example.com. They visit a malicious web page at attacker.example.com. The malicious page contains JavaScript that opens a WebSocket connection to wss://chat.example.com/ws/chat. The browser sends the request — and because the user is logged in, it automatically includes their session cookie in the upgrade headers. The server sees a valid session cookie and accepts the connection.
The attacker's page can now receive every message the server sends to that session and inject messages as if they were the authenticated user. This attack — called Cross-Site WebSocket Hijacking (CSWSH) — is the WebSocket analogue of Cross-Site Request Forgery (CSRF).
Message Injection
Even without CSWSH, an attacker who can observe or intercept a WebSocket upgrade request over an unencrypted ws:// connection can steal the session token from the Cookie header. With that token, they can open their own WebSocket connection authenticated as the victim and inject messages — commands, chat messages, financial orders — that the server processes as legitimate.
Research into enterprise collaboration platforms (including reports related to Slack's WebSocket infrastructure in 2019) and numerous trading platform incidents have demonstrated how severe the consequences of message injection can be in production systems.
What You Will Do
In the interactive panel on the right you will observe a live WebSocket message stream, inject a message as another user, and use the Handshake Inspector to steal the session token from the upgrade headers. By the end of this exercise you will understand exactly where session tokens travel and why per-message authentication is essential.