Cross-Origin Resource Sharing (CORS) - am I missing something here?

Question

I was reading about CORS and I think the implementation is both simple and effective.

However, unless I'm missing something, I think there's a big part missing from the spec. As I understand, it's the foreign site that decides, based on the origin of the request (and optionally including credentials), whether to allow access to its resources. This is fine.

But what if malicious code on the page wants to POST a user's sensitive information to a foreign site? The foreign site is obviously going to authenticate the request. Hence, again if I'm not missing something, CORS actually makes it easier to steal sensitive information.

I think it would have made much more sense if the original site could also supply an immutable list of servers its page is allowed to access.

So the expanded sequence would be:

1. Supply a page with list of acceptable CORS servers (abc.com, xyz.com, etc)
2. Page wants to make an XHR request to abc.com - the browser allows this because it's in the allowed list and authentication proceeds as normal
3. Page wants to make an XHR request to malicious.com - request rejected locally (ie by the browser) because the server is not in the list.

I know that malicious code could still use JSONP to do its dirty work, but I would have thought that a complete implementation of CORS would imply the closing of the script tag multi-site loophole.

I also checked out the official CORS spec (http://www.w3.org/TR/cors) and could not find any mention of this issue.

Answer 1

But what if malicious code on the page wants to POST a user's sensitive information to a foreign site?

What about it? You can already do that without CORS. Even back as far as Netscape 2, you have always been able to transfer information to any third-party site through simple GET and POST requests caused by interfaces as simple as form.submit(), new Image or setting window.location.

If malicious code has access to sensitive information, you have already totally lost.

3) Page wants to make an XHR request to malicious.com - request rejected locally

Why would a page try to make an XHR request to a site it has not already whitelisted?

If you are trying to protect against the actions of malicious script injected due to XSS vulnerabilities, you are attempting to fix the symptom, not the cause.