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