Stop Ignoring WebSockets — There Are P1s to Be Found

Most bug bounty hunters scroll past WebSocket traffic. That's a mistake. There are P1-severity vulnerabilities hiding in plain sight, and almost nobody is looking for them.

What Are WebSockets?

Unlike standard HTTP — where every request demands a response and connection overhead stacks up — WebSockets create a persistent, bi-directional communication channel. Once the connection is opened, data flows freely in both directions without repeating HTTP headers on every round-trip.

They're the backbone of real-time chat apps, live gaming, collaborative tools, and trading platforms. If an application updates in real time, there's a good chance WebSockets are involved.

How the Handshake Works

The magic begins with a standard HTTP request. The client sends a GET with two critical headers:

Connection: Upgrade
Upgrade: websocket

If the server agrees, it responds with HTTP 101 Switching Protocols. The connection persists, and the protocol shifts from http:// to ws:// — or wss:// if TLS is involved. From that point, it's a raw, open pipe to the backend.

Why WebSockets Are a Bug Bounty Goldmine

Two structural weaknesses make WebSockets uniquely exploitable:

• Authentication gaps: Developers often authenticate the initial handshake but forget to authorize the individual messages passed back and forth after the connection opens. The door gets checked; everything inside goes unchecked.
• WAF blindspots: Traditional Web Application Firewalls struggle to inspect persistent binary or custom-framed WebSocket traffic. Once the upgrade happens, it's essentially a dark tunnel straight to the backend — a natural WAF bypass.

Top Vulnerabilities to Hunt

1. CSWSH — Cross-Site WebSocket Hijacking

If the server relies solely on cookies for authentication during the handshake and doesn't validate the Origin header, an attacker can trick a victim's browser into opening a WebSocket connection to the target server — and then read all data flowing through it. Think of it as CSRF, but for persistent connections.

2. IDOR & Unauthorized Access

Many apps expose API-style commands over WebSockets without enforcing session validation. Sending a crafted payload like:

{"user_id": 1337, "action": "delete"}

…may execute without any server-side check that you're actually authorized to act on that user ID.

3. Injection — XSS & SQLi

WebSocket messages often flow into internal dashboards or database queries with no sanitization. Dropping a blind XSS or SQLi payload into the WebSocket stream can trigger execution on an internal admin panel that's never directly exposed to the internet.

Toolkit

You can't hack what you can't see. Build your WebSocket hunting setup with these tools:

• Burp Suite: The WebSockets History tab and Repeater are your core tools. Intercept, modify, and replay frames with precision.
• STEWS: An automated tool for WebSocket endpoint discovery and vulnerability fingerprinting — great for initial recon.
• wscat: A lightweight CLI client for raw WebSocket connections. Perfect for manual probing and quick payload testing without a full proxy setup.

The next time you open Burp and see WebSocket traffic, don't skip it. Dig in — that persistent connection might be your next critical finding.

Source: Bugcrowd on X