WebSocket Security and Authentication in Spring Boot
Fast recall
Quick revision
Core answer
Awareness that WebSocket connections bypass typical Spring Security filter chains after the upgrade.
Sending tokens in WebSocket message payloads instead of at the handshake level, or not authorizing STOMP destinations separately.
Explain that STOMP CONNECT frames carry credentials that Spring Security can validate with an inbound ChannelInterceptor.
Interview-ready guide
Interview answer
WebSocket security has a fundamental gap that HTTP doesn't: after the 101 Switching Protocols upgrade, your entire Spring Security filter chain stops applying to frames.
- The
@PreAuthorizeannotations, URL-based rules, CSRF tokens — none of them see WebSocket frames. - You need to secure at two layers: the HTTP handshake and the STOMP message channel.
Handshake security — the HTTP layer:
- Since the browser's WebSocket API cannot attach custom headers, tokens arrive as query parameters —
ws://host/ws?token=eyJ...; aHandshakeInterceptorvalidates the JWT before the server sends 101 - Rejecting at the handshake prevents allocating server memory for unauthorized long-lived connections — far more efficient than allowing the connection and then rejecting STOMP frames
STOMP channel security — the message layer:
- A
ChannelInterceptorintercepts the CONNECT frame and binds aPrincipalto the STOMP session from the token stored in handshake session attributes - The part most teams miss: without intercepting SUBSCRIBE commands, any authenticated user can subscribe to
/user/admin/queue/reportsand receive another user's private messages; pattern-match the destination against the authenticated principal
Token expiry on long-lived connections:
- A JWT issued at connect time might expire while the socket stays open for hours or days; check the token expiry timestamp on every SEND command and prompt the client to reconnect and re-authenticate before expiry
- Long-lived connections with expired tokens represent stale authorization that could persist indefinitely if not actively managed
I recommend a security checklist: authenticate at handshake time with query parameter token, authorize at the channel level with destination pattern matching, and plan for token expiration with client-side reconnect prompting.
WebSocket Security and Authentication in Spring Boot
Direct Answer
Authenticate at the HTTP handshake using HandshakeInterceptor or Spring Security's channel interceptor. Pass a JWT via query param or cookie at connect time, validate it in the interceptor, and store the principal in session attributes. Then authorize STOMP destinations with ChannelInterceptor.
Common Mistakes & Pitfalls
Sending tokens in WebSocket message payloads instead of at the handshake level, or not authorizing STOMP destinations separately.
Check your understanding
Answer these without looking back at the article.
- Why can't you pass a JWT in an HTTP Authorization header when using SockJS?
- How would you handle token expiration for a long-lived WebSocket connection?
- How do you prevent users from subscribing to another user's private queue?
Related interview prep categories
1Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.