Are there any negative consequences to enabling CORS for all resources?

Question

CORS is a great thing.

Especially when we have webservices that are called from a cloud-based CRM that doesn't contain our domain name.

BUT, it is it an unalloyed good? I am feeling pressure to make all resources from our ReST-ish webservices serve out CORS headers.

I'm nervous that CORS may expose a 'hole' in our design... And my instinct is that information-hiding is what makes programming not devolve into spaghetti code.

Is there any literature about when CORS-ifying your resources goes too far? (I haven't found any, but I may not be looking in the right places)

This is close to the answer I'm looking for: [link](http://stackoverflow.com/questions/9713644/when-is-it-safe-to-enable-cors), but I'm curious if there's any other opinions floating out there. — user1673777, Oct 16 '12 at 17:59

score 2 · Answer 1 · edited Jun 20 '20 at 09:12

According to the WhatWG, using Access-Control-Allow-Origin: * is safe so long as your app is not behind a firewall:

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.

My understanding is that auth/cookies are not sent unless the request is made with the withCredentials flag set, and if the withCredentials flag is set, wildcarding the resource is not allowed.

In other words, auth credentials are never supplied if Access-Control-Allow-Origin doesn't have the sending domain whitelisted.

score 0 · Answer 2 · answered Dec 19 '12 at 03:46

As with most things in software engineering (and in life), the answer depends on context. Specifically the context of what the API is serving and who is accessing the API.

What type of data is the API serving? Is it specific to a particular user? Is it user-sensitive or time-sensitive? Does it require authentication?

Who is accessing the API? Is it open to everyone, or is it only a single person/organization? What client libraries will users use to to access the API? Is access from a web browser and JavaScript important?

This last question is the most important: if your user has no need to access data from a web browser, then CORS may not be the right fit for your API.

Think of a chart with "users" on the x-axis and "data" on the y-axis, with each axis ranging from "restricted" to "open":

               ^ Open
               |
               |
               |
               |
               |
USERS <------------------->
  Restricted   |        Open
               |
               |
               |
               |
               v Restricted
              DATA

The more open your data and users needs are (upper right quadrant), the better fit CORS is for your API. However this is only a general rule, and you will need to evaluate your own API based on the questions above.

Are there any negative consequences to enabling CORS for all resources?

2 Answers2