-
Security
Authenticate and authorize my WebSocket connections
Adds auth to socket handshakes, per-channel authorization, and rate limiting to real-time features.
Free Prompt
Audit my WebSocket (or realtime) layer for auth gaps. Look at connection setup, channel/room subscriptions, and message handlers.
Apply: the handshake authenticates the user the same way HTTP requests do (session cookie or token validated server-side on upgrade, not a user ID passed by the client and trusted); every channel or room subscription checks authorization server-side (joining "user-123-notifications" requires being user 123); every incoming message is validated like any API input (schema, size limits, rate limits per connection), since a socket is an open pipe around your HTTP middleware; and disconnects clean up server-side state. If the app broadcasts events, confirm per-user events never leak into channels other users can join.
Do not change the event names or message shapes the client uses. Do not add a separate auth system; reuse the existing session mechanism at the handshake.
Deliver: the handshake auth, the per-channel checks added, message validation, and a test plan: connect without credentials (refused), join another user's channel (refused), and send oversized or malformed messages (rejected without crashing the socket server).
What This Does / How This Helps
Brings your real-time layer up to the same standard as your HTTP API: authenticated connections, authorized channels, and validated messages. WebSockets bypass the middleware stack that protects your HTTP routes, so apps with decent API security often have a wide-open socket server next to it. Joining any room by name, sending events as any user, flooding messages: all of it works unless someone checks, and in generated code nobody checked. The test plan mirrors what an attacker would try: no credentials, someone else's channel, and garbage payloads.
Want to skip doing this by hand?
Fortivibe audits your app for all of the areas these prompts cover (and more).