Securing STOMP Endpoints with Spring Security
Learn how to authenticate and authorize STOMP messaging in Spring, securing the handshake, destinations, and per-user messages against unauthorized access.
Securing STOMP Endpoints with Spring Security is a free WebSockets & Real-Time Systems with Spring lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the WebSockets & Real-Time Systems with Spring learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Secure STOMP?
An open STOMP endpoint lets anyone subscribe to and publish on any destination. Securing STOMP ensures only authenticated users connect and only authorized users access specific destinations.
This lesson layers Spring Security onto STOMP messaging.
Two Layers of Security
STOMP security operates at two levels:
- Handshake: authenticate the user when the WebSocket connection opens
- Message: authorize each SUBSCRIBE and SEND to a destination
Both layers are needed for real protection.
Authenticating the Handshake
The connection should carry the user's identity. With session-based auth, Spring Security propagates the HTTP session principal into the WebSocket session automatically.
Token Auth on CONNECT
For token-based auth, read the token from the STOMP CONNECT frame headers using a ChannelInterceptor and set the authenticated principal on the message.
@Override
public Message<?> preSend(Message<?> message, MessageChannel channel) {
StompHeaderAccessor acc = StompHeaderAccessor.wrap(message);
if (StompCommand.CONNECT.equals(acc.getCommand())) {
String token = acc.getFirstNativeHeader('Authorization');
Authentication user = tokenService.validate(token);
acc.setUser(user);
}
return message;
}Authorizing Destinations
Spring provides AbstractSecurityWebSocketMessageBrokerConfigurer to define which roles may access which destinations, similar to HTTP security rules.
@Override
protected void configureInbound(MessageSecurityMetadataSourceRegistry messages) {
messages
.simpDestMatchers('/app/admin/**').hasRole('ADMIN')
.simpSubscribeDestMatchers('/topic/public').permitAll()
.anyMessage().authenticated();
}Per-User Destinations
The /user/** prefix routes messages to a single user's private queue. Spring resolves these against the authenticated principal, so users only receive their own messages.
// Server side: send to a specific user
messagingTemplate.convertAndSendToUser(
username, '/queue/notifications', payload);CSRF Considerations
The WebSocket handshake is an HTTP request and can be subject to CSRF. Validate origins and, where applicable, require a CSRF token so attackers cannot open connections from malicious pages.
Restricting Origins
Always lock down allowed origins for the STOMP endpoint. An open origin policy lets any website connect on behalf of a logged-in user.
@Override
public void registerStompEndpoints(StompEndpointRegistry registry) {
registry.addEndpoint('/ws')
.setAllowedOrigins('https://app.example.com')
.withSockJS();
}Validating Message Payloads
Authentication is not enough; validate the content of every message. Reject oversized payloads, unexpected fields, and malformed data to prevent injection and resource exhaustion.
- Enforce size limits
- Validate against a schema
- Reject unknown destinations
Logging Security Events
Log failed connections, denied subscriptions, and authorization failures. These events feed monitoring and help detect abuse or probing of your messaging layer.
Defense in Depth
Combine handshake auth, destination authorization, origin restriction, and payload validation. No single control is sufficient; layered controls keep your real-time messaging secure even if one fails.
Quick Check
Test your understanding of STOMP security.
Recap
You learned to secure STOMP at two layers: authenticate the handshake (session or token), then authorize destinations with Spring Security rules. Per-user destinations, origin restrictions, payload validation, and event logging together provide defense in depth for real-time messaging.
Frequently asked questions
Is the “Securing STOMP Endpoints with Spring Security” lesson free?
Yes — the full text of “Securing STOMP Endpoints with Spring Security” is free to read here on the web, and the WebSockets & Real-Time Systems with Spring course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the WebSockets & Real-Time Systems with Spring course, upgrade to CoddyKit PRO.
What will I learn in “Securing STOMP Endpoints with Spring Security”?
Learn how to authenticate and authorize STOMP messaging in Spring, securing the handshake, destinations, and per-user messages against unauthorized access. You practise WebSockets & Real-Time Systems with Spring with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start WebSockets & Real-Time Systems with Spring?
No prior experience is required. WebSockets & Real-Time Systems with Spring on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Securing STOMP Endpoints with Spring Security” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this WebSockets & Real-Time Systems with Spring lesson?
Yes. Every WebSockets & Real-Time Systems with Spring lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Introducing STOMP Protocol
- Configuring STOMP with Spring
- Sending and Receiving STOMP Messages
- Securing STOMP Endpoints with Spring Security