Search code examples
safaricontent-security-policy

Safari Gives Error "Refused to connect to _____ because it does not appear in the connect-src directive of the Content Security Policy."

I have a online whiteboard that Safari users cannot connect to. They get the following from the console.

Refused to connect to wss://whiteboard.[MYDOMAIN].com/[MOREPATHSTUFF] because it does not appear in the connect-src directive of the Content Security Policy.

Only Safari does this. Chrome, FF, Edge, etc. work fine. I've looked over other SO related posts and it seems that Safari requires something like...

<meta http-equiv="Content-Security-Policy" content="
                        default-src * data: blob: ws: wss: gap://ready file://*;
                        style-src * 'unsafe-inline'; 
                        script-src * 'unsafe-inline' 'unsafe-eval';
                        connect-src * ws: wss:;">

I have no idea what all of this means though. All I want is for Safari to allow the connection and all should be well. Thanks for the consideration on how to make that happen.

Solution

  • I've looked over other SO related posts and it seems that Safari requires something like...

    You already have a Content Security Policy (CSP) been published via an HTTP header or meta tag (how to check it), because a violation message appears in the browser console.
    Publishing the second CSP cannot relax the resulting policy, since the first CSP will still perform a blocking.
    That's why you couldn't fix the problem by adding a meta tag or HTTP header.

    You have to figure out where the first CSP is published and to make changes to it.

    Only Safari does this. Chrome, FF, Edge, etc. work fine.

    Safari supports the connect-src directive, so its behaviour should not differ from Chrome/Firefox/Edge except one thing: Safari does not support upgrade ws: to wss:.
    In case of connect-src ws:, the Chrome/Firefox/Edge will apply connect-src ws: wss: policy, but Safari does not.

    I bet you have connect-src ws: in the CSP, therefore all connection to wss: are blocked.
    When you find where your CSS is published, just add wss://whiteboard.[MYDOMAIN].com to connect-src directive.

    Note: if you are using the default-src directive instead of connect-src - then you need to add wss://whiteboard.[MYDOMAIN].com into it.

    Update:
    How CSP header can be issued

    A). A CSP header can be published in your web app itself (Helmet middleware, specific packages for managing HTTP headers, direct issue an HTTP header via res.setHeader() and so on).

    B). CSP header can be published by server. For Nginx it should be add_header Content-Security-Policy "default-src ... "; in the server config. Several folders can be used for that but etc/nginx/conf.d is preferred, others are deprecated.

    What if I publishes CSP header in both ways A) and B) at the same time?

    Server works after your web app software did all job, therefore web-server (or proxy-server) should override an HTTP header with the same name. So server can override any HTTP header published by web app.

    In some cases it's not work and you can see that 2 CSP headers been published. Even in this case you can make a trick:

    proxy_hide_header Content-Security-Policy;

    and then immediately under that, add header how fo you need it:

    add_header Content-Security-Policy "default-src 'self';";

    This can be used as a temporary solution until you figure out where the header is really published.