← ClaudeAtlas

websocket-securitylisted

Secure WebSocket endpoints: Origin validation, auth on handshake, message size/rate limits, wss-only, reconnection backoff — Applies to: when generating a WebSocket / Socket.IO / SignalR server; when wiring real-time messaging, presence, or collaborative editing; when reviewing /ws or wss:// endpoint exposure
ShieldNet-360/secure-vibe · ★ 3 · Web & Frontend · score 76
Install: claude install-skill ShieldNet-360/secure-vibe
<!-- Native skill bundle for agent-skills (cross-tool convention). Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/websocket-security/SKILL.md. --> # WebSocket Security Secure WebSocket endpoints: Origin validation, auth on handshake, message size/rate limits, wss-only, reconnection backoff ## ALWAYS - Validate the **`Origin` header** on the WebSocket upgrade handshake against an allowlist. CORS does **not** apply to WebSockets — the browser will happily upgrade cross-origin and let JavaScript on `attacker.com` open `wss://api.example.com/ws` with the user's cookies (Cross-Site WebSocket Hijacking). - Require authentication **on the handshake** itself, not as the first message after connect. Either: 1. Cookie-based auth on the HTTP upgrade (and CSRF-protect by verifying Origin), or 2. A short-lived signed token (5–10 minute lifetime) in the `Sec-WebSocket-Protocol` subprotocol header, or 3. A signed query parameter token. Never trust a `subscribe` / `auth` message after the upgrade — by that point the connection has already been opened with the authenticated cookie context. - Use **`wss://`** only in production. Plain `ws://` over the open internet exposes session tokens, message contents, and CSRF primitives to any on-path observer. - Enforce **max message size** at the server (typical: 32 KiB for chat, 256 KiB for collaborative editing, much higher only when the use case demands it and the auth bar is high). Without