WebSockets keep a long-lived, bidirectional connection open between client and server, which introduces security challenges that don't apply to normal stateless HTTP requests.
Key Points: • The initial handshake happens over HTTP, so it's vulnerable to Cross-Site WebSocket Hijacking if the origin isn't validated. • A stolen or hijacked connection lets an attacker send or intercept messages for the life of that session. • Standard per-request security filters (like CSRF tokens on each call) don't naturally apply once the connection is upgraded. • Long-lived connections make it harder to revoke access mid-session if a token expires or a user is deauthorized. • Unencrypted ws:// traffic exposes message contents; wss:// (TLS) should always be used in production.
Example: A chat application using ws:// without origin checks could let a malicious site open a WebSocket to the server on a logged-in user's behalf and read their private messages.
Interview Tip: A concise interview answer is:
"WebSockets stay open for the life of the session, so the usual per-request checks like CSRF tokens don't apply after the handshake, and a hijacked connection can be abused for as long as it's alive. I'd mitigate this by validating the Origin header during the handshake, authenticating with a short-lived token before upgrading, and always using wss:// for encryption."