I have searched all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Problem Description
Open WebUI's WebSocket server does not enforce CORS (Cross-Origin Resource Sharing) origin validation on WebSocket connections. While WebSocket endpoints are protected by authentication mechanisms, they lack the same origin validation that HTTP endpoints have.
Without CORS validation on WebSockets, there's a potential attack vector for Cross-Site WebSocket Hijacking (CSWSH), where a malicious website could attempt to establish WebSocket connections if it somehow obtains valid authentication tokens (e.g. through XSS on a different subdomain, browser extensions, or other token leakage scenarios).
This is a defense-in-depth concern rather than an immediate vulnerability, but it represents a gap in the security layers that should be addressed for consistency and best practices.
Desired Solution you'd like
Add CORS origin validation to the WebSocket server configuration by utilizing the existing CORS_ALLOW_ORIGIN environment variable that's already used for HTTP endpoints.
Alternatives Considered
Leave as is
Additional Context
This was raised while we had a team do a thorough security review of Open WebUI
Originally created by @ricdikulous on GitHub (Oct 18, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18410
### Check Existing Issues
- [x] I have searched all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
### Problem Description
Open WebUI's WebSocket server does not enforce CORS (Cross-Origin Resource Sharing) origin validation on WebSocket connections. While WebSocket endpoints are protected by authentication mechanisms, they lack the same origin validation that HTTP endpoints have.
Without CORS validation on WebSockets, there's a potential attack vector for Cross-Site WebSocket Hijacking (CSWSH), where a malicious website could attempt to establish WebSocket connections if it somehow obtains valid authentication tokens (e.g. through XSS on a different subdomain, browser extensions, or other token leakage scenarios).
This is a defense-in-depth concern rather than an immediate vulnerability, but it represents a gap in the security layers that should be addressed for consistency and best practices.
### Desired Solution you'd like
Add CORS origin validation to the WebSocket server configuration by utilizing the existing `CORS_ALLOW_ORIGIN` environment variable that's already used for HTTP endpoints.
### Alternatives Considered
Leave as is
### Additional Context
This was raised while we had a team do a thorough security review of Open WebUI
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @ricdikulous on GitHub (Oct 18, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18410
Check Existing Issues
Problem Description
Open WebUI's WebSocket server does not enforce CORS (Cross-Origin Resource Sharing) origin validation on WebSocket connections. While WebSocket endpoints are protected by authentication mechanisms, they lack the same origin validation that HTTP endpoints have.
Without CORS validation on WebSockets, there's a potential attack vector for Cross-Site WebSocket Hijacking (CSWSH), where a malicious website could attempt to establish WebSocket connections if it somehow obtains valid authentication tokens (e.g. through XSS on a different subdomain, browser extensions, or other token leakage scenarios).
This is a defense-in-depth concern rather than an immediate vulnerability, but it represents a gap in the security layers that should be addressed for consistency and best practices.
Desired Solution you'd like
Add CORS origin validation to the WebSocket server configuration by utilizing the existing
CORS_ALLOW_ORIGINenvironment variable that's already used for HTTP endpoints.Alternatives Considered
Leave as is
Additional Context
This was raised while we had a team do a thorough security review of Open WebUI