Adding websocket origins to connect-src to support Safari
Context
With &6363, we're fixing all issues related to Content Security Policy, so it can be re-enabled for self-hosted customers. At the moment, the MR changes should affect only dev & test environments.
What does this MR do?
This MR solves an issues due to which Web Socket connections were blocked in Safari.
Why?
The connect-src directive is currently set to 'self' in https://gitlab.com/gitlab-org/gitlab/-/blob/f55df3d80f96f5de344f5e19fdb382f7759136ff/lib/gitlab/content_security_policy/config_loader.rb#L17
In CSP Level 2, 'self' strictly meant "same origin" however that definition was extended in CSP Level 3 and now 'self' includes https/wss variations of the origin.
Reference
Unfortunately, Safari still hasn't moved to that new definition so we have to explicitly support wss://GITLAB_DOMAIN and ws://GITLAB_DOMAIN.
Screenshots or screen recordings
- Content-Security-Policy in the HTTP Response headers
| before | after |
|---|---|
 |
 |
- Setting up WS connections in Safari Browser
| before | after |
|---|---|
 |
 |
How to set up and validate locally
With this change when you open GitLab locally, esc on Safari, you should see wss://127.0.0.1:3000 and ws://127.0.0.1:3000 origins added to the connect-src directive.
This should allow Web Socket connections from the same domain which can be quickly tested using the steps below. For instance, if your gdk runs at 127.0.0.1:3000, it should not throw CSP exception for these commands:
new WebSocket('wss://127.0.0.1:3000')
new WebSocket('wss://127.0.0.1:3000')
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Closes #337967 (closed)