CORS security: reflecting any origin header value when configured to * is dangerous about cors

[chenjj]

Hi Olivier, thanks for your reply.

Yeah, setting credentials to false by default can reduce misconfigurations, but the point I want to say here is that, converting Origin: * and Credentials: true to origin reflection is insecure and incompatible with CORS standards.

Current CORS standards(both W3C CORS and WHATWG fetch standard) have a clear definition for the wildcard *, which means any domain is allowed. But they also have another important security requirement: Origin: * and Credentials: true cannot be used at the same time, to avoid overly loose permissions. Currently all browsers follow this requirement to disallow this configuration combination.

If a framework actively converts * to reflect any origin header value, it means Origin: * and Credentials: true can be used at the same time. This behavior leads to CORS protocol's security design to be bypassed, causing many misconfiguration security problems.

Therefore, I suggest frameworks to follow the standard definition of *. When a user configures Origin:*, frameworks just directly returns Access-control-Allow-Access: *. When a user configures both Origin:* and Credentials: true , frameworks should warn users that this is a misconfiguration because browsers will not accept this combination.

[rs]

This is only the case when allow credential is enabled, which is not the default. What change would you expect?

[chenjj]

FYI, here are some more similar issues:
Yii2 framework, yiisoft/yii2#16193
Tomcat CORSFilter, CVE-2018-8014, https://bz.apache.org/bugzilla/show_bug.cgi?id=62343

[rs]

Please see #56

[rs]

@chenjj any feedback?

[chenjj]

Looks good, thanks!