Recently I've watched a video about how to hack a game called Club Penguin, using a vulnerable websocket. In the other day I was facing my first websocket vulnerability in a engagement. That wasn't even the original target…

Thanks to YuriRDev (link to the video)

What I found wasn't a single catastrophic vulnerability. It was something more subtle — and a lot more interesting.

Small architectural decisions, when combined, can quietly expand your attack surface.

Let's break it down.

1. How WebSocket Works (And Why It's Powerful)

WebSocket is a protocol designed to maintain a persistent, bidirectional connection between client and server.

Unlike traditional HTTP — which follows a request > response > close pattern — WebSocket establishes a handshake and then keeps the connection open. After that, both client and server can exchange messages in real time without reopening new connections.

This makes it ideal for dynamic, interactive systems.

But it also changes the security model.

With REST APIs, every request is explicit. With WebSockets, the channel stays open — and events flow continuously.

That persistence requires careful access control.

2. Common Use Cases for WebSocket

WebSockets are widely used in applications that depend on real-time communication, such as:

  • Chat systems
  • Live notifications
  • Monitoring dashboards
  • Streaming logs
  • Collaborative tools

In modern architectures, they're everywhere.

And because they feel like "background infrastructure," they often receive less scrutiny than REST endpoints.

That's where things can go wrong.

3. What I Found — Part 1: Event Segregation Issues

While analyzing the WebSocket endpoint during the exercise, I manually connected to the channel used by the application.

Once connected, I observed the stream of events being transmitted in real time.

The issue? - The event stream did not appear to enforce strict user-level segregation.

In other words, the connection was receiving more contextual information than it should have within its own scope.

This suggested insufficient authorization checks at the event level.

In WebSocket implementations, it's not enough to authenticate during the handshake. Authorization must be enforced continuously and per event.

4. What I Found — Part 2: Chained Weaknesses

Individually, none of the issues I identified would necessarily qualify as critical.

However, combined, they significantly increased the attack surface:

  • Weak account creation controls
  • Predictable resource identifiers in URLs
  • Insufficient validation when accessing certain resources
  • Lack of strict segregation in real-time event streams

This is a classic example of vulnerability chaining.

Security weaknesses rarely exist in isolation. They compound.

An attacker doesn't need a single "critical" flaw. They need a path.

5. How to Prevent These Issues

WebSockets must be treated with the same security rigor as REST APIs.

Some key principles:

  • Strong authentication during the handshake process.
  • Authorization validation not just at connection time, but for every event emitted or received.
  • Strict channel segregation based on user identity, tenant, or role.
  • Non-predictable identifiers for sensitive resources.
  • Consistent enforcement of the principle of least privilege.
  • Real-time communication should never mean reduced control.
  • Persistent connections require persistent security.

Final Thoughts

This finding reinforced something I strongly believe:

Modern security is no longer just about protecting HTTP endpoints.

Every persistent channel, every background stream, every real-time event pipeline is part of your attack surface.

If you're building or reviewing systems that use WebSockets, ask yourself:

Are we validating authorization per event? Or only at connection time?

Because in real-time architectures, small gaps can move very fast.