Allow configuration of Access-Control-Allow-Origin value

[flenter]

Allows responses with a specified Access-Control-Allow-Origin value instead of:
Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: <req.headers.origin>

The kind of change this PR does introduce

• a bug fix
• a new feature
• an update to the documentation
• a code change that improves performance
• other

Current behaviour

In several places the Access-Control-Allow-Origin header is set to either '*' or to the
value that was part of the request. This gives the impression that CORS is always allowed.

There are two scenarios where this happens:

• errors that are sent via the sendErrorMessage in lib/server.js
• responses by the XHR transport

New behaviour

It's now possible to specify an origins value (default value is '*') when initialising the engine. This value will be returned as the Access-Control-Allow-Origin value.

Note: this pr does not add support for verifying/checking the origins values, socket.io by default passes a function that performs this check already (via the allowRequest option).

Other information (e.g. related issues)

There will be an accompanying PR for socket.io that passes the origins value it has to this package (once this pr is merged or has gotten some feedback).

Related issue:

• Engine.io to not set CORS headers on error response: Engine.io to not set CORS headers on error response #449

[darrachequesne]

@flenter may I ask what use case you have in mind (which would not be covered by the allowRequest option)?

[flenter]

I think it helps if I explain how I came to this pr:
A vulnerability scanner found this problem it send a get request to /socket.io and got a 400 repsonse with CORS headers set to '*'. After some digging I found that this is default behaviour in several places in the code.

What allowRequest didn't cover

If you specify origins on socket.io a allowRequest function will be passed to engine.io that checks if a request is allowed based on the origins setting. The error response however ignores this and can respond with Access-Control-Allow-Origin: '*' if the origins header was not set (and otherwise returns the requests origin header value).

The new origins option is used for two things, the first one is to return the correct header for errors handled by the sendErrorMessage function. The second use is explained below.

The PR however contains another change and that came up after I noticed that the long-polling transport behaves similarly to the error handling function regarding CORS header values. This is why the opts object is added to transports constructor. It allows the origins value to be passed to the (xhr-polling) transport and the responses can contain the correct CORS header values.

[flenter]

Is there anything I can do to help progress this pr?

[uncinimichel]

+1

[pratheekhegde]

When will this PR get merged? Is there any blocker?

[flenter]

I've rebased the pr so there are no more merge conflicts

[mooflu]

As an alternative, would it be easier to provide official api access to the headers before they are written. We ran into the same issue as @flenter where a penetration testing suite flagged socket.io as having arbitrary origins trusted. Our current approach is to register for the socket connection's transport 'headers' event as well as intercept the response's writeHead for the handshake in allowRequest (no access to socket transport at that stage) and modify the headers. Needless to say, that's icky. In our case we don't even need CORS at all.

[holm]

Would be really good to have this issue sorted out one way or the other.

[Kreijstal]

I approve of this

[darrachequesne]

Merged! Sorry for the delay..