[Feature request] A more powerful custom origin calculation method depending on other headers

Currently this middleware only allows you to dynamically resolve the CORS header value depending on the origin of the incoming request, but sometimes this isn’t enough and more information about the request is necessary to make the decision.

Something like this would be nice:

cors({
  origin: (req: express.Request) => {...}
})

Here’s a use case: An app has header-based-authentication (a token is passed along with each request) and an Access-Control-Allow-Origin: * value, cause CSRF attacks are kind of impossible - there’s no cookies to be forwarded and an attacker would have to somehow steal the token from some other origin’s localStorage or something (which is impossible AFAIK) to be able to use it with an API call.

But then there’s a plan to also enable session-based-authentication for the same app. This changes security constraints, however, because now a Access-Control-Allow-Origin: * value is def going to allow CSRF attacks to happen, cause even if the API call is invoked from attacker.com the cookie is going to be forwarded alongside the request and will allow the attacker to use the API with the browser user’s cookie.

One solution to that problem (the best one IMO) is to calculate a Access-Control-Allow-Origin value differently depending on which authentication method is used. If there’s an Authorization header, then Access-Control-Allow-Origin: * is fine, but if there’s a session cookie header instead, then Access-Control-Allow-Origin will have to be more limited and only allow specific approved origins.

If needed I can do a PR for this, just let me know if you accept the premise and will merge it once it’s done

[dougwilson]

So the way CORS itself works (unrelated to this module) is that it’s a “double-opt-in” system. The idea is that the client has no idea if the web server supports CORS and so it needs a way to probe that. What they did was create a “pre-flight” request whenever the original request was not a “safe request” – that is, if the request is not one of the “simple verbs” and/or it contains auth-like headers like Cookie, Authortization, etc. So when that is the case, the web browser will first make that “pre-flight request” which is the veb OPTIONS and includes none of the body content and headers from the original request, and that request is where your decision needs to happen on what the Access-Control-Allow-Origin and etc. headers contain. If it doesn’t contain the Origin then the web browser will fail and never make the original request.

Your example wants to decide between two cases that are both “non-safe” and thus they would both use a pre-flight, at which point, it would not be possible to tell which is which case but you need to supply a Access-Control-Allow-Origin to get the original request to be made, of course.

I hope that makes sense.

[dougwilson]

I don’t think that is feasable with CORS. Have you verified? Because either the Cookie header or the Authorization header would be included in the CORS OPTIONS request by the web browser, which is the point at which the Origin header would need to be responded to. This is because the pre-flight request (OPTIONS method) only contains a small subset of headers that are defined in the CORS spec.