📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
🎯 BUG BOUNTY MASTERY
FREE
Part of the Bug Bounty Mastery Course
Day 23 of 60 · 38.3% complete
⚠️ 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 ### 📋 WebSocket Bug Bounty Day 23 — Contents 1. How WebSockets Work — The Security Difference From HTTP 2. Finding WebSocket Endpoints in Bug Bounty Targets 3. Cross-Site WebSocket Hijacking — Detection and Exploitation 4. Message Injection and Authentication Bypass 5. Burp Suite WebSocket Testing Workflow 6. Reporting WebSocket Vulnerabilities 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 FORCopy
Initial HTTP Upgrade request — this is your attack surface
GET /chat HTTP/1.1
Host: target.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://target.com
Cookie: session=abc123
Server response — 101 = connection accepted
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
What CSWSH looks for: missing Origin validation
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
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)