First, let's talk about the same origin policy. I'll quote from a previous answer of mine:
The same-origin policy was invented because it prevents code from one website from accessing credential-restricted content on another site. Ajax requests are by default sent with any auth cookies granted by the target site.
For example, suppose I accidentally load http://evil.com/
, which sends a request for http://mail.google.com/
. If the SOP were not in place, and I was signed into Gmail, the script at evil.com
could see my inbox. If the site at evil.com
wants to load mail.google.com
without my cookies, it can just use a proxy server; the public contents of mail.google.com
are not a secret (but the contents of mail.google.com
when accessed with my cookies are a secret).
(Note that I've said "credential-restricted content", but it can also be topology-restricted content when a website is only visible to certain IP addresses.)
Sometimes, however, it's not evil.com
trying to peek into your inbox. Sometimes, it's just a helpful website (say, http://goodsite.foo
) trying to use a public API from another origin (say, http://api.example.com
). The programmers who worked hard on api.example.com
want all origins to access their site's contents freely. In that case, the API server at api.example.com
can use CORS headers to allow goodsite.foo
(or any other requesting origin) to access its API responses.
So, in sum, we assume by default that cross-origin access is a bad thing (think of someone trying to read your inbox), but there are cases where it's a good thing (think of a website trying to access a public API). CORS allows the good case to happen when the requested site wants it to happen.