Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is it safe to enable CORS to * for a public and readonly webservice?

Tags:

security

cors

Enabling CORS has several security issues:

  • CSRF
  • exposure of protected data

But are there any issues for a public and readonly webservice to enable global CORS?

Access-Control-Allow-Origin: *

My assumptions:

  • CSRF is not relevant, because webservice is readonly.
  • stealing of protected data is not relevant, because webservice is public.
like image 405
Matthias M Avatar asked Apr 01 '17 07:04

Matthias M


People also ask

Is it safe to enable CORS?

CORS adds another layer of security to help ensure that only trusted domains can access your site's resources. As mentioned above, most CORS vulnerabilities relate to poor validation practices due to response header misconfigurations. These relax security too much and allow non-trusted origins to access resources.

Is Access-Control allow Origin * Safe?

Access-Control-Allow-Origin: * is totally safe to add to any resource, unless that resource contains private data protected by something other than standard credentials. Standard credentials are cookies, HTTP basic auth, and TLS client certificates.

Is CORS a security risk?

Many modern websites use CORS to allow access from subdomains and trusted third parties. Their implementation of CORS may contain mistakes or be overly lenient to ensure that everything works, and this can result in exploitable vulnerabilities.

Should I allow CORS on my API?

So if you have an API that is designed to be only used by XHR, you can (and should) require the request to conform with CORS. Especially if the requests can also modify state on your server as otherwise you would be vulnerable to CSRF.


2 Answers

Here’s something relevant from the Fetch spec (which defines CORS):

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.

And the author of the Fetch/CORS spec goes into a bit more detail in a related blog posting:

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!

like image 98
sideshowbarker Avatar answered Oct 08 '22 10:10

sideshowbarker


If it is a public API then CORS should be enabled for all requests. One of the best security approach for public APIs is using app keys in request headers.

like image 39
Justus Ikara Avatar answered Oct 08 '22 12:10

Justus Ikara