CSP: connect-src 'self' and websockets

[mikewest]

From @klings on September 28, 2015 19:25

Declaring a CSP with connect-src ‘self’ will not allow websockets back to the same host/port, since they're not same origin. This might come as a surprise to developers that haven't studied the CSP specification in detail and have a firm grasp of the same origin security model.

One option could be to add a note to the spec to clarify that this is the intended behaviour. Another option could be to make an exception for connect-src 'self', and allow ws(s): requests to same host/port.

I'm not sure what the security implications could be of the latter, but it might be worth some consideration.

Copied from original issue: w3c/webappsec#489

[zdexter]

I'm not sure this should be intended behavior - what about the "load web page in browser, then make websocket connection" use case? Nobody wants to enumerate all possible websocket origins in server configuration files or switch on development/production/staging hostnames... that's the utility of 'self' in the first place. Described scenario here: w3c/webappsec#506.

[mikewest]

Poked at this in 0e81d81, WDYT?

[klings]

Thanks for looking into this! This should do the trick for same host/port web sockets.

[amacneil]

Would it also be possible to support ws: if the current protocol is http: and the CSP allows connect-src 'self'? It sounds like as written self will only support wss: if the current page was served via http.

As an example, it would be useful to serve a page at http://localhost:3000/ using connect-src 'self', and have this behave as if the CSP (under current rules) had specified connect-src 'self' ws://localhost:3000.

[thapet]

This seems still to be an issue - like amacneil described. I have tried with connect-src 'self', but ws request to same origin (host and port) does not work (when testing from remote machine).
I have tried with Chrome v.59 and Edge v.14.

[annevk]

Reopening this per recent comment. It seems this wasn't fixed properly yet.

[emilfihlman]

Issue opened at: https://bugs.chromium.org/p/chromium/issues/detail?id=815142

[emilfihlman]

New development https://bugs.chromium.org/p/chromium/issues/detail?id=815142#c8

[Thesephi]

Sincere apologies if I'm asking in a wrong thread, but I think Safari also has the same issue as specified in a previous comment by thabet (although I tested with https & wss) (I tested on Safari 12.1.1 and Safari Technology Preview Release 87 (Safari 13.0, WebKit 14608.1.33.1)). Internet search didn't result in productive findings, so I decided to ask here. Could anyone else reproduce?

[ratiofu]

@Thesephi I can reproduce in Safari 12.1.2 with CSP connect-src 'self'. In fact, because of that error, I landed here. I filed WebKit bug 201591

[MoxxiManagarm]

I just came here because of the same. Still reproducable with Safari 13. Other browser accept wss to self with connect-src 'self' defined.

[mikewest]

I believe the spec is correct, and covered by https://wpt.fyi/results/content-security-policy/connect-src/connect-src-websocket-self.sub.html?label=experimental&label=master&aligned. Closing this out again, as the bug against WebKit is the right place to comment on priority.

/cc @johnwilander

[mkurz]

There is finally work going on to get this fixed in Safari: https://bugs.webkit.org/show_bug.cgi?id=235873 (before it was https://bugs.webkit.org/show_bug.cgi?id=201591, which was marked as duplicate)

[mkurz]

https://bugs.webkit.org/show_bug.cgi?id=235873 is finally resolved now, so this should be fixed in the next Safari release 16 (maybe even 15.5 or 15.6 if those will happen)

[silverwind]

Maybe it's a regression but I do observe this exact issue in Firefox 120.0b9 where connect-src: self does not allow ws://localhost:3000 when origin is http://localhost:3000. Works fine on 119.0.1.

[mkurz]

@silverwind I think you should report that to the firefox bug tracker?

[silverwind]

I will if I reproduce again. Strangely enough downgrading and upgrading Firefox seems to have resolved it for now.

[skyzyx]

I spent way too much time today going spelunking through issues and patch notes this morning.

The WPT test for this was added in September 2018.

• It was already fixed in Firefox Dev and Stable. [source] (September 2018)

• It was fixed in Chrome 71.0.3559.6 (Dev) when it was announced on the Chrome blog (commit 15b59a4d4fe5524b5cb006747831aa1c47012e75). [source, source] (September 2018)

• It was fixed in WebKit r292266, which was released in Safari Technology Preview 144, although it didn't make the release notes until 145 was released a week later [source, source] (May 2022)

• That WebKit fix made it into Safari 16.0. [source] (September 2022)

• Edge 17 (EdgeHTML) already had support when the test was written. It inherited that support when adopting Chromium in 2019.

• With Opera switching to Chromium in 2013, I would assume that it received patches from upstream Chromium (September 2018) when that bug was fixed. (It is not tested as part of the WPT test suite.)