Spring WebSocket STOMP identity: authenticate the handshake, authorize destinations

Identity comes from the HTTP entry

A browser authenticates the WebSocket HTTP handshake. Spring associates the resulting Principal with the STOMP session; STOMP login and passcode headers are ignored by default for WebSocket authentication. A client-supplied userId header is still client input. The subscription and SEND destinations need message authorization, even after the handshake succeeds. The STOMP boundary describes the endpoint and broker roles.

Separate subscription from command permission

An operator may subscribe to /user/queue/receipts but must not SEND to a broker-owned /topic/stock route. Authorize inbound SEND and SUBSCRIBE message types and destination patterns through Spring Security's message authorization manager. A broker destination is not an application command. Bind tenant information to the authenticated principal and validate it again in the message handler; the tenant claim rule still applies.

Test the message channel

Open a connection with no authenticated HTTP session and attempt CONNECT. Then authenticate, try an allowed private subscription and a forbidden broad topic. Assert the rejected frame never reaches the handler or broker. Browser origins and CSRF behavior also need an application test. The code is a configuration sketch, not a complete security chain.

Implementation sketch

messages
    .simpDestMatchers("/app/receipts/**").hasAuthority("SCOPE_receipts.write")
    .simpSubscribeDestMatchers("/user/queue/receipts").authenticated()
    .simpSubscribeDestMatchers("/topic/admin/**").hasRole("ADMIN")
    .anyMessage().denyAll();

Cost and verification

Authorization runs for inbound messages. That cost is small compared with allowing an unbounded SEND or SUBSCRIBE route; per-message database lookups should be measured and cached carefully.

Common Mistakes

• Do not trust STOMP login/passcode or userId headers as verified identity.
• Do not authorize CONNECT and leave SEND or SUBSCRIBE destinations open.
• Do not let clients SEND directly to broker-owned notification topics.

Read next

Spring WebSocket and STOMP: authenticate the handshake, authorize messages, Spring JWT tenant claims: reject missing or malformed ownership before conversion, Spring STOMP slow clients: send buffer and message-size limits, Spring STOMP simple broker versus relay: the multi-instance boundary.