5

The question is for the security community to resolve some misunderstandings here.

The crux:

  • Company (Wire) has a client (official-client.com) and a server code (e.g. official-server.com ).
  • CORS currently allow official-client.com to access official-server.com, but unofficial-client.com does not have access to official-server.com
  • The code for official-client is available for reuse for custom applications (supposedly, to host on unofficial-client.com)

The use case here is straightforward: exposing auth protected API services to others. And the definition of "others" is currently set to "official-client.com" only.

Question: What benefit is there in not having? 

Access-Control-Allow-Origin: *

To quote another article, it appears the app is not as secure if it relies on its security by restricting resource access to one domain (as the domain can be faked with DNS/local hosts). But that's not really the issue.

What am I missing?

mr.meer
  • 53
  • 3
  • 1
    CORS is not about security, it's about protecting copyright owner's IP. When you want everyone to be able to consume the domain's data, then `*` makes sense. a bank doesn't want that... – dandavis Feb 16 '18 at 18:54
  • 1
    @dandavis Not true at all. With badly configured CORS you could read private information from a user's session on another website, for example private messages, bank details, etc. There was even a recent cryptocurrency wallet vulnerability based around misconfigured CORS. – Polynomial Feb 16 '18 at 23:51
  • 2
    @Polynomial: those examples would imply not just a CORS problem, but an auth problem as well. Anything CORS would stop, a python script could ignore. It closes _some_ vectors, but not all, and thus should not be relied upon as security in and of itself. I watched CORS grow up, as an amelioration to JSONP's ills, and security wasn't a huge factor in it's development. – dandavis Feb 17 '18 at 14:38
  • 2
    @dandavis Sending a cross-origin request still submits the browser's stored cookies for the target domain. – Polynomial Feb 17 '18 at 16:09

1 Answers1

4

The CORS policy prevents a malicious website from gaining access to data on other domains. For example, foo.com should not be able to read the contents of bar.com via an ajax request or similar mechanism. If you set the Access-Control-Allow-Origin header to *, it allows any domain on the internet to send a request to your domain.

By default, when no Access-Control-Allow-Origin header is set, the default SOP applies and requests can only be made from the same domain.

DNS poisoning is irrelevant here, as the purpose of CORS is to prevent the leakage of information to other hosts. If the server uses HTTPS, you will not be able to man-in-the-middle the connection or impersonate the server, which doesn't gain you anything.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • 2
    Nice response-- I do want to specify (it's merely semantics, but it's important for readers to understand) that when you say "If you set the Access-Control-Allow-Origin header to *, it allows any domain on the internet to send a request to your domain.", what's really being said is "it allows any domain on the internet to send a request to your domain and read information on it". Basically, even with a restrictive CORS policy, domains can still SEND requests, they just will not be accepted by the remote application. Maybe not necessary, but I felt like it's an important nuance. – plast1K Feb 17 '18 at 15:30