Skip to content
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

Wrong Approach Being Taken #147

Open
dubahu opened this issue Dec 27, 2019 · 1 comment
Open

Wrong Approach Being Taken #147

dubahu opened this issue Dec 27, 2019 · 1 comment

Comments

@dubahu
Copy link

dubahu commented Dec 27, 2019

I think the approach of telling everyone to set CORS to * without explaining what they are exposing and giving up is wrong. While one could argue that blindly accepting solutions without research is lazy, you could also say that providing solutions without explanation is equally lazy. There are a good number of resources available that explain what CORS is, what it protects from and how to use it. Some are below. There are very few instances where wildcard needs to be used. Even if you have more than 1 origin, you can use a list and use regex to rewrite headers to only use orgins you specify. Googling CORS multiple origins and the web server you are using should yield results on how to do that. In short, you shouldn't use * unless you TRULY need to allow every possible site on the internet to do cross origin requests to your stuff, which is probably not the case unless you are hosting shared js or css, like a CDN for example.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://auth0.com/blog/cors-tutorial-a-guide-to-cross-origin-resource-sharing/
https://www.html5rocks.com/en/tutorials/cors/
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

@sideshowbarker
Copy link

https://stackoverflow.com/a/43154277/441757
https://fetch.spec.whatwg.org/#basic-safe-cors-protocol-setup

Basic safe CORS protocol setup

For resources where data is protected through IP authentication or a firewall (unfortunately relatively common still), using the CORS protocol is unsafe. (This is the reason why the CORS protocol had to be invented.)

However, otherwise using the following header is safe:

Access-Control-Allow-Origin: *

Even if a resource exposes additional information based on cookie or HTTP authentication, using the above header will not reveal it. It will share the resource with APIs such as XMLHttpRequest, much like it is already shared with curl and wget.

Thus in other words, if a resource cannot be accessed from a random device connected to the web using curl and wget the aforementioned header is not to be included. If it can be accessed however, it is perfectly fine to do so.

https://annevankesteren.nl/2012/12/cors-101

It is completely safe to augment any resource with Access-Control-Allow-Origin: * as long as the resource is not part of an intranet (behind a firewall). In other words, a URL you can fetch from a server on the internet using wget or curl. For your basic web site this encompasses all resources on the site. The Access-Control-Allow-Origin header (part of CORS) tells the browser the resource can be shared.

Even if the resource includes confidential information based on cookies or HTTP authentication data in the request, including the header and sharing the resource is still safe, since the browser will make the request without any cookies or HTTP authentication data. And if the browser did make the request with cookies or HTTP authentication data, it would never share the resource because that would require an additional header, Access-Control-Allow-Credentials, and a different value for the aforementioned header.

So go ahead and safely share your public data with other applications!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants