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.
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)