WebSockets move the security boundary from one request to a long-lived connection. That changes what must be authenticated, rate-limited, validated, and closed.
Authenticate the connection and the actions
Validate the session during the handshake, but do not treat that as permission for every message. Authorization belongs at the action boundary too: a connected user should only read rooms, resources, or records they are allowed to access.
Short-lived, single-use tickets can keep browser credentials out of the WebSocket URL. The server should verify the ticket, consume it atomically, and reject reuse.
Treat every message as hostile input
Parse JSON inside a guarded boundary. Check the message type, required fields, lengths, and allowed values before business logic runs. Reject unknown message shapes instead of silently accepting fields that future code may interpret.
Sanitize content according to where it will be rendered. Escaping HTML in the browser is not a substitute for validating message size and structure on the server.
Limit the connection
Use limits for connection attempts, messages per connection, message bytes, rooms joined, and total open connections per identity. Add heartbeats so dead sockets do not remain in memory forever.
Graceful shutdown matters too. Stop accepting new connections, notify active clients, close the server, and wait for the database and queue resources to finish. A deploy should not leave half-open sessions behind.
Log enough to investigate
Record safe identifiers, close reasons, authentication outcomes, and rate-limit events. Do not log tokens, message bodies, passwords, or arbitrary client-controlled strings as if they were trusted metadata.
A secure WebSocket service is not just a successful handshake. It is a set of boundaries that remain enforced for the entire lifetime of the connection.