WebSockets enable full-duplex, real-time communication for chat systems, trading dashboards, collaborative editors, and notifications. However, because WebSockets operate over persistent TCP connections established via an HTTP upgrade handshake, they bypass many standard browser security protections like the Same-Origin Policy.
Cross-Site WebSocket Hijacking (CSWSH)
When a browser initiates a WebSocket connection (`wss://app.example.com/ws`), it automatically attaches existing session cookies for that domain. If the server does not validate the `Origin` header during the HTTP handshake, a malicious third-party site can open a WebSocket connection to your API and hijack the user's live session.
- Handshake Origin neglect: failing to validate the incoming `Origin` header during the initial HTTP upgrade request.
- Missing per-message authorization: verifying permissions only during the handshake, but failing to validate whether subsequent incoming messages are authorized for the active user.
- Unencrypted transports: using plain `ws://` instead of TLS-encrypted `wss://`, exposing messages to local network eavesdropping.
Hardening real-time WebSocket channels
Validate the `Origin` header against an explicit allowlist during the handshake. Use one-time cryptographic connection tokens passed via query parameters rather than relying purely on ambient cookies. Enforce strict authorization checks on every incoming message event frame.
Always validate the Origin header on the WebSocket upgrade handshake and verify authorization for every action dispatched over the socket.