Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

socket.io Content-Security-Policy Host #90

Open
theage opened this issue Jul 27, 2016 · 3 comments
Open

socket.io Content-Security-Policy Host #90

theage opened this issue Jul 27, 2016 · 3 comments

Comments

@theage
Copy link

theage commented Jul 27, 2016

What is the recommended practice to define a sensible CSP to allow socket.io requests?

The host name may be known only upon receiving a request with the Host:, so I cannot configure the CSP string statically because 'self' does not apply to web sockets on the ws:// / wss:// protocols.

@shaunwarman
Copy link
Member

Hey @theage

You should have no problem adding your ws:// uri to the connect-src CSP directive in lusca. So you would have something like:

...
"connect-src": "'self' ws://<hostname> wss://<hostname>"
...

@theage
Copy link
Author

theage commented Oct 19, 2016

@shaunwarman, the issue is that the hostname is dynamically inferred from the Host: header (at runtime), but lusca wants a hard-coded header, so basically I have to send the CSP header myself rather than have lusca do it, unless there is a way to have a function resolve it.

"connect-src": () => { ... return `'self' ws://${request.hostname} wss://${request.hostname}` }

@shaunwarman
Copy link
Member

shaunwarman commented Oct 19, 2016

Hmm interesting. Could you elaborate on the dynamic host? Is this an auto-scaled environment where the ws:// server name relys on host machine?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants