BIPI
BIPI

WebSocket Vulnerabilities in 2026: Hijacking and Beyond

Cybersecurity

WebSocket security gets less attention than HTTP, which is exactly why CSWH and missing per-message auth keep paying out. Here's the WebSocket pentest playbook and the controls that protect persistent connections.

By Arjun Raghavan, Security & Systems Lead, BIPI · January 14, 2025 · 7 min read

#websocket#web-security#pentest

WebSockets bypass most of the assumptions web developers have about HTTP: same-origin policy is loose, cookies are sent automatically, and authentication is often performed only at the handshake. The result is a parallel attack surface most teams under-test.

How to test for it

Burp's WebSocket history captures every frame. Send candidate frames to WebSocket Repeater, modify, and replay. ZAP's WebSockets tab gives equivalent functionality. For automated probing, websocat is the go-to CLI and wsrepl ships scriptable replay.

Cross-Site WebSocket Hijacking

CSWH is CSRF for WebSockets. Browsers do not enforce CORS preflight on WebSocket upgrades, so any origin can open a wss:// connection that includes the victim's cookies. If the server uses cookie auth and skips Origin validation, the attacker can read and write to the victim's session.

  • Open the target socket from a malicious page using new WebSocket('wss://victim.example.com/api/ws') and verify the connection succeeds with Origin: https://attacker.com.
  • Capture the post-handshake messages: if the server sends user data immediately after connect, you have CSWH read primitive.
  • Send messages on the socket and verify they execute under the victim's identity for CSWH write primitive.
  • Test Sec-WebSocket-Protocol manipulation when servers use it for auth tokens.

Per-message auth gaps

Many backends authenticate the handshake then trust every subsequent frame without re-checking authorization. Probe by opening as user A, then sending an action message that references user B's resource. If the server processes it because the connection is authenticated rather than the message being authorized, you have a privilege escalation.

Other WebSocket attacks

Message flooding for DoS: send 10000 frames per second and watch for backend crash or queue exhaustion. Frame size attacks: send a frame with a length field of 2GB and watch memory pressure. Compression attacks (CRIME-style) when permessage-deflate is on. Smuggling-style attacks where HTTP and WebSocket protocols are confused at intermediate proxies.

Detection

Log every WebSocket handshake with Origin, User-Agent, and authenticated user. Alert on Origin values that do not match the application's known frontends. Log message rate per connection and disconnect on threshold breach. Alert on messages that reference resources outside the connected user's scope.

Remediation

  1. Validate the Origin header on every WebSocket handshake against an allowlist. Reject anything else with HTTP 403.
  2. Use a CSRF token in the WebSocket URL or in the first post-handshake frame. Include it in the connection request and verify before accepting any message.
  3. Authorize every message, not just the handshake. Treat each frame as a fresh API call with its own permission check on the resource it references.
  4. Rate limit per connection: messages per second, total bytes, total connections per IP. Disconnect on breach.
  5. Cap frame size at the smallest value the protocol needs (often 64KB is plenty). Reject larger frames at the proxy layer.
  6. Use a token in Sec-WebSocket-Protocol or as a query param rather than relying on cookies, since this disables automatic browser cookie attachment and kills CSWH outright.

Validation

From an attacker-controlled origin, attempt to open the socket with default browser flow and confirm rejection. From a normal session, send a message referencing another user's resource and confirm 403. Run a load test that floods the socket and confirm graceful disconnect. BIPI's WebSocket assessments enumerate every message type, build a permission matrix, and validate per-message authorization across the full protocol.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.