Cross-Site WebSocket Hijacking (CSWSH): A Practical Guide

Cross-Site WebSocket Hijacking (CSWSH): A Practical Guide

Cross-Site WebSocket Hijacking is essentially CSRF for WebSockets. If a WebSocket handshake authenticates using cookies and the server does not validate the Origin header, a malicious page can open an authenticated socket to the target on the victim's behalf — then read or send messages as that user.

It is under-tested because many hunters ignore WebSocket traffic entirely.

Why the handshake matters

A WebSocket connection starts as an HTTP request with an Upgrade: websocket header. Browsers send cookies automatically on that request. If the server:

• Authenticates the socket using those cookies, and
• Does not check that Origin is a trusted site,

then any origin can establish an authenticated connection. That is the whole bug.

Detection workflow

1. Find WebSocket endpoints (look for ws:///wss:// in traffic and JS, or Upgrade: websocket handshakes).
2. Inspect the handshake: is authentication cookie-based? Is there a token in the URL or a header instead?
3. Check whether the server validates Origin — replay the handshake with a different Origin and see if it still succeeds.

If cookie auth works with an arbitrary origin, CSWSH is likely.

Build a safe proof-of-concept

1. Host a simple page on an origin you control.
2. From that page, open a WebSocket to the target endpoint while logged into your own test account in the same browser.
3. If the socket connects and returns authenticated data (for example your own messages or session info), capture that as proof.

Exfiltrate only your own account's data to your own listener. Never pull another user's messages.

Impact

• Reading private real-time data (chat, notifications, live account info)
• Sending actions over the socket as the victim
• Chaining leaked data (tokens, IDs) into further attacks

Because it is silent and needs only a victim visit, impact is often medium-to-high depending on what the socket exposes.

Common false positives

• Sockets authenticated by a token in the URL/message (not ambient cookies) — usually not CSWSH
• Servers that enforce Origin (your cross-origin handshake fails)
• Connections that carry no sensitive data or actions

Report structure

Show the handshake, the missing origin validation, your cross-origin PoC page, and the authenticated data or action obtained with your own account. Recommend strict Origin allowlisting on the handshake plus CSRF-style tokens for socket auth.

Defensive checklist

• Validate the Origin header on every WebSocket handshake.
• Prefer token-based authentication sent in the connection, not ambient cookies alone.
• Use CSRF tokens or a per-session challenge for socket setup.
• Scope socket data to the authenticated principal and re-check authorization per message.
• Add tests that attempt cross-origin handshakes.

CSWSH rewards hunters who treat WebSockets as first-class attack surface. Replay a handshake from a foreign origin — if it still authenticates, you've found it.

Original Bugflare guide informed by PortSwigger cross-site WebSocket hijacking material.