Issue: WebSocket Token in URI #2538

New Issue

MrUnknownDE · 2026-04-06T03:46:33+02:00

MrUnknownDE commented

2026-04-06 03:46:33 +02:00

Originally created by @Berndinox on 3/26/2021

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 3/26/2021* ### 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_

MrUnknownDE closed this issue

2026-04-06 03:46:33 +02:00

Sign in to join this conversation.

No Label enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement enhancement troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting troubleshooting

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/vaultwarden#2538