[GH-ISSUE #1544] Issue: WebSocket Token in URI #999

New issue

Closed

opened 2026-03-03 02:05:24 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 02:05:24 +03:00

Owner

Originally created by @Berndinox on GitHub (Mar 26, 2021).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1544

Subject of the issue

I dont want my Token to be sent via URI
After authentication JWT Token is transmitted in HTTP Header as usually. However Bitwarden is also trying to establish an WebSocket Connection for Realtime. For that porpose the following URL is called:
wss://domain.com/notifications/hub?access_token=JWT_TOKEN

That call can easily be logged without breaking the SSL Connection. (Forward-Proxy, Reverse-Proxy, Wireshark)

An Attacker can use that token to get access to the account.
YES, the passwords are still client side encrypted so there is no "super-danger".

However, in my optionion a password-manager should not send long living Token via URI.

See also: https://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param
"This method is included to document current use; its use is not recommended, due to its security deficiencies (see Section 5) and also because it uses a reserved query parameter name, which is counter to URI namespace best practices, per "Architecture of the World Wide Web, Volume One" [W3C.REC‑webarch‑20041215]."

Temporary Token with short lifetime could fix that issue.

EDIT:
What is strange, that i still log this after setting: WEBSOCKET_ENABLED: "false"

WebSocket connection to 'wss://domain.com/notifications/hub?access_token=TOKEN' failed: Error during WebSocket handshake: Unexpected response code: 403

403 is just because i have not rule for /notification/hub to Websocket Port

Originally created by @Berndinox on GitHub (Mar 26, 2021). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1544 ### Subject of the issue I dont want my Token to be sent via URI After authentication JWT Token is transmitted in HTTP Header as usually. However Bitwarden is also trying to establish an WebSocket Connection for Realtime. For that porpose the following URL is called: wss://domain.com/notifications/hub?access_token=JWT_TOKEN That call can easily be logged without breaking the SSL Connection. (Forward-Proxy, Reverse-Proxy, Wireshark) An Attacker can use that token to get access to the account. **YES, the passwords are still client side encrypted so there is no "super-danger".** However, in my optionion a password-manager should not send long living Token via URI. See also: https://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param "This method is included to document current use; its use is not recommended, due to its security deficiencies (see Section 5) and also because it uses a reserved query parameter name, which is counter to URI namespace best practices, per "Architecture of the World Wide Web, Volume One" [W3C.REC‑webarch‑20041215]." Temporary Token with short lifetime could fix that issue. EDIT: What is strange, that i still log this after setting: WEBSOCKET_ENABLED: "false" WebSocket connection to 'wss://domain.com/notifications/hub?access_token=TOKEN' failed: Error during WebSocket handshake: Unexpected response code: 403 _403 is just because i have not rule for /notification/hub to Websocket Port_

kerem

2026-03-03 02:05:24 +03:00

closed this issue
added the
enhancement

troubleshooting
labels

kerem commented

2026-03-03 02:05:25 +03:00

Author

Owner

@jjlin commented on GitHub (Mar 27, 2021):

I dont want my Token to be sent via URI
After authentication JWT Token is transmitted in HTTP Header as usually. However Bitwarden is also trying to establish an WebSocket Connection for Realtime. For that porpose the following URL is called:
wss://domain.com/notifications/hub?access_token=JWT_TOKEN

That call can easily be logged without breaking the SSL Connection. (Forward-Proxy, Reverse-Proxy, Wireshark)

This is how upstream Bitwarden works currently, so there's nothing bitwarden_rs can do about it if it wants to remain compatible. I don't know if upstream would consider this to be a feature request, but you could try https://community.bitwarden.com/c/feature-requests/5 or https://github.com/bitwarden/server/issues.

What is strange, that i still log this after setting: WEBSOCKET_ENABLED: "false"

WebSocket connection to 'wss://domain.com/notifications/hub?access_token=TOKEN' failed: Error during WebSocket handshake: Unexpected response code: 403

403 is just because i have not rule for /notification/hub to Websocket Port

This is expected. The web/browser/desktop clients always try to establish a WebSocket connection, regardless of whether the server has it enabled (I'm not sure the upstream server even allows you to disable WebSockets).

@jjlin commented on GitHub (Mar 27, 2021): > I dont want my Token to be sent via URI > After authentication JWT Token is transmitted in HTTP Header as usually. However Bitwarden is also trying to establish an WebSocket Connection for Realtime. For that porpose the following URL is called: > wss://domain.com/notifications/hub?access_token=JWT_TOKEN > > That call can easily be logged without breaking the SSL Connection. (Forward-Proxy, Reverse-Proxy, Wireshark) This is how upstream Bitwarden works currently, so there's nothing bitwarden_rs can do about it if it wants to remain compatible. I don't know if upstream would consider this to be a feature request, but you could try https://community.bitwarden.com/c/feature-requests/5 or https://github.com/bitwarden/server/issues. > What is strange, that i still log this after setting: WEBSOCKET_ENABLED: "false" > > WebSocket connection to 'wss://domain.com/notifications/hub?access_token=TOKEN' failed: Error during WebSocket handshake: Unexpected response code: 403 > > _403 is just because i have not rule for /notification/hub to Websocket Port_ This is expected. The web/browser/desktop clients always try to establish a WebSocket connection, regardless of whether the server has it enabled (I'm not sure the upstream server even allows you to disable WebSockets).

kerem commented

2026-03-03 02:05:25 +03:00

Author

Owner

@BlackDex commented on GitHub (Mar 27, 2021):

Upstream doesn't allow to disable it. Actually, the only reason we have that option i think is because there is no native integration with rocket right now.

@BlackDex commented on GitHub (Mar 27, 2021): Upstream doesn't allow to disable it. Actually, the only reason we have that option i think is because there is no native integration with rocket right now.