I think you are misunderstanding where and why CORS is used. It is not intended to prevent a script from calling out to an untrusted server (with an Access-Control-Allow-Origin: *
header, for example), since that is often a valid use case. The default, restrictive policy doesn't even restrict whether data can be sent; even without that header from the server, a client can send arbitrary data that will be received by the server.
Here's an example where the default policy is helpful:
Say you have an intranet website that provides sensitive company information. An attacker knows the website exists, and crafts some cross-origin AJAX requests in JavaScript to exfiltrate data from the website if any company users browse to the attacker-controlled website. When this happens, the JavaScript will reach out to the intranet server, but will refuse to return any data due to no Access-Control-Allow-Origin
header.
Another scenario is where an attacker knows you are logged into a social media website, and wants to read your private chats. The attacker writes some JavaScript to pull messages from whatever user is logged in, using cross-origin requests when you visit their website. This is also prevented without the aforementioned header.
In either scenario, the attacker can't read any cross origin data since the target websites do not bear the necessary header to relax the policy. The attacker does not control these headers, as they do not have access to the systems in question.
Furthermore, by using my own server as a proxy, and spoofing headers,
I can essentially make any HTTP call to any server in the world,
regardless of their CORS settings
Maybe, but what does this gain you? You can't accomplish either of the two scenarios I provided above, especially since credentials won't be sent to the wrong domain.