Closed Kcchouette closed 8 years ago
I attended a OWASP conference a couple of weeks ago. CORS was mentioned there in one example as a bad practice.
OWASP cheat sheet about CORS: https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Cross_Origin_Resource_Sharing
And a blog post about it too, with an exploit example code https://www.insinuator.net/2013/08/some-security-impacts-of-html5-cors-or-how-to-use-a-browser-as-a-proxy/
Since Hummingbird V3 will no longer have any cookies (instead using OAuth2 tokens) the plan is to enable CORS.
I'm not sure why OWASP is against CORS, I'm pretty sure it keeps your cookies safe to prevent CSRF (though I'm not honestly sure) and that's honestly the only real problem (besides preflights, see below). Lucky for us, we won't have cookies so it's actually perfectly safe to expose everything! If you wanna act as a user, you'll need to get their permission and have an oauth2 token first.
That said, if speed is a desire, you'll want to proxy the requests to avoid CORS preflights, as they double the round trips
I'm pretty sure it keeps your cookies safe to prevent CSRF
As it turns out, this is configurable via a header on the response. But, well, we don't have cookies in V3, so this is very much not an issue!
Not a security expert. Worked in many projects where CORS was enabled (Header set Access-Control-Allow-Origin ""). I think the issue they talked about was enabling the access to '' which could be used in an attack.
But I shouldn't have posted here. Thinking better now, since HummingBird API will be exposed to all, it probably makes sense to be permissive and enable it to all.
Sorry for the noise :-)
I found very important to not forget that for your next version (and if you can your oldest version too) of the API.
Because I can't reopen #644, I create this new one.
Some informations available on #644:
Thanks