API vulnerabilities with dynamic cors headers

Question

I've been reading up on how to properly secure APIs that support dynamic cors headers. Not sure if I fully understand the problem with wildcarding any subdomain.

if (preg_match('|\.?my-site.com$|', $_SERVER['SERVER_NAME'])) {
   header('Access-Control-Allow-Origin: *');
   header('Vary: Origin,Accept-Encoding');
}

(My API supports both HTTP and HTTPS, and is fronted by Varnish)

questions

1. Is there a drawback to using Access-Control-Allow-Origin: * vs the actual origin making the request?
2. What security benefits do I gain by adding Vary: Origin, Accept-Encoding? I read about the need for them when reading about cache poisoning, but can't say I understand the implications here.

Answer 1

Is there a drawback to using Access-Control-Allow-Origin: * vs the actual origin making the request?

The only drawback in the case outlined in the question is that if you want to include credentials in the request, you can’t if the Access-Control-Allow-Origin value is *. See Credentialed requests and wildcards in the MDN HTTP access control (CORS) article.

So it seems like what you probably want to be doing instead is, have your PHP code take the value of the Origin request header and echo that back in the Access-Control-Allow-Origin value:

if (preg_match('|\.?my-site.com$|', $_SERVER['SERVER_NAME'])) {
   header("Access-Control-Allow-Origin: {$_SERVER['HTTP_ORIGIN']}");
   header('Vary: Origin,Accept-Encoding');
}

Not sure if I fully understand the problem with wildcarding any subdomain.

The only case where allowing requests from any origin is a problem is if your service is running inside an intranet or behind a firewall.

See the related answer at Is it safe to enable CORS to * for a public and readonly webservice?

Answer 2

1. You'll find a cool answer here: What are the security risks of setting Access-Control-Allow-Origin? :

Let's imagine you're holding a bank website, which is using cookie based sessions. Writing Access-Control-Allow-Origin: * would allow any website to run an Ajax request from their website to your bank website using your user's cookies, and thus, your user's session. So they can access anything the user can access when they're connected :-)

2. I don't think it is linked to security, but here is an interesting answer from this page:

Vary: Accept-Encoding basically tells the server to load the page from the cache when the encoding is the same, and to re-generate it for another encoding. Here is a quote from the page above that explains a case for which it is useful:

Imagine two clients: an old browser without compression, and a modern one with it. If they both request the same page, then depending on who sent the request first, the compressed or uncompressed version would be stored in the CDN. Now the problems start: the old browser could ask for a regular “index.html” and get the cached, compressed version (random junk data), or the new browser could get the cached, uncompressed version and try to “unzip” it. Bad news, either way.