-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CORS security: reflecting any origin header value when configured to * is dangerous #55
Comments
This is only the case when allow credential is enabled, which is not the default. What change would you expect? |
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 Current CORS standards(both W3C CORS and WHATWG fetch standard) have a clear definition for the wildcard If a framework actively converts Therefore, I suggest frameworks to follow the standard definition of |
FYI, here are some more similar issues: |
Please see #56 |
@chenjj any feedback? |
Looks good, thanks! |
When CORS policy is configured to origin:"*", current go CORS handler will actively convert it to reflect any Origin header value. This kind of behavior is dangerous and has caused many security problems in the past.
Some similar security issues:
cyu/rack-cors#126
https://nodesecurity.io/advisories/148
Some related blog posts:
http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html
https://ejj.io/misconfigured-cors/
The text was updated successfully, but these errors were encountered: