1

The security department of the company I work for is against (rightly so) Access-Control-Allow-Origin: * on the socket.io requests.

The app is not using CORS at all, this is the problem only with socket.io requests.

This is the function I am using to start socket.io after the server is ready:

exports.start = (server) => {
    io = exports.socketio.socket.listen(server, {
        origins: `https://${server.address().address}:*`,
        rejectUnauthorized: false,
        wsEngine: 'ws',
        transports: ['websocket', 'polling']
    });

    exports.connect();
};

The issue with that is that first: - server.address().address returns something like this :: - I need to deploy the app on multiple servers with different addresses - previously there was no origins property and socket.io was setting the origing to *

- when I test the solution on my local machine setting the origins to: 'https://localhost:3000' I am still getting Access-Controll-Allow-Origin: * for some socket.io requests.

enter image description here

Has someone already encountered this issue ?

Any help much appreciated

matewilk
  • 1,191
  • 1
  • 13
  • 27

1 Answers1

0

The problem with an automated server.address().address is that in production your server may not report the actual publicly visible server address because that public IP address may be a load balancer or a proxy or something like that and it is the public IP address (the one the browser connects to) that must be in the origins field. Your server itself can have a different IP address than what is publicly associated with your domain.

CORS issues with socket.io are caused only because socket.io by default uses http polling first and then switches over to an actual webSocket. webSocket connections all by themselves are not subject to CORS limitations. So, you can configure the client to ONLY connect with a real webSocket and then you won't have any CORS issues at all.

You can see how to use webSockets only here: Socket.io 1.x: use WebSockets only?

The only downside I know of for that is that your socket.io connection will not work in older browsers that don't support webSockets yet. For browsers that might still be in use in any meaningful quantity, that would really only be versions of IE before IE11 which looks to be about 2.5%. Some will argue that people still using IE8 are either likely less internet-savvy users or are in a very tightly controlled company and are less likely to be participating in new internet services so the relevance to a new internet service is even less than 2.5%.

If you're curious, in January 2016 Microsoft announced the dates that they would stop supporting versions of IE earlier than IE11 and all those dates have since passed (so there are no regular bug fixes for old versions of IE any more).


An alternative would be to create a config file which your server reads upon startup where whomever is deploying your server can add the public IP address or domain that should be used with CORS.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • Thank you for your answer, that all makes sense, I tried the solution you mention in the answer, but I couldn't make it work, we are using socket.io version 2.0.4. and setting it to use `websocket` as transport didn't prevent from sending `polling` requests at the start. (probably some config option I haven't gone through yet). For `origins` option I even hardcoded the ip addresses on the test server both for the socket.io-client and the socket.io server and I still got Access-Control-Allow-Origin set to * but as you are saying it might be because of load balancers or proxies, I host it on AWS – matewilk Nov 23 '17 at 13:27