As I learned from this post, when page from www.a.com makes AJAX request to www.b.com, then it's the www.b.com that decides if request should be allowed or not.
Not quite. The request isn't blocked (at least, if it is simple).
By default the JavaScript running on www.a.com is forbidden access to the response from www.b.com.
CORS provides a means by which www.b.com can give permission to the JavaScript on www.a.com to access the response.
But what is exactly secured on client in such model?
It stops the author of www.a.com from reading data from www.b.com using the browser of a User who has visited both sites and has been authenticated on www.b.com (and thus has access to data that isn't public).
For example, Alice is logged into Google. Alice visits malicious.example which uses XMLHttpRequest to access data from gmail.com. Alice has a GMail account so the response has a list of the most recent email in her inbox. The same origin policy prevents malicious.example from reading it.
For example, hacker success to make XSS script injection to my page, then it makes AJAX request to his domain to store user data. So hackers domain will allow such request for sure.
Correct. XSS is a different security problem that needs to be addressed at source (i.e. at www.a.com and not in the browser).
Important note up front: If the server at the other end doesn't enable it, there's nothing you can do in your client-side code that will allow a cross-origin ajax request.
Let me give you a background before answering your question:
Simply put, same-origin security policy makes sure that scripts from one origin may not fetch content from other origins. Now to explain you the concept of origin, let me quote part of the Wikipedia article of Same-Origin Security Policy:
The following table gives an overview of typical outcomes for checks against the URL "http://www.example.com/dir/page.html".
Compared URL Outcome Reason
------------------------------------------------------- ------- ----------------------
http://www.example.com/dir/page2.html Success Same protocol and host
http://www.example.com/dir2/other.html Success Same protocol and host
http://username:[email protected]/dir2/other.html Success Same protocol and host
http://www.example.com:81/dir/other.html Failure Same protocol and host but different port
https://www.example.com/dir/other.html Failure Different protocol
http://en.example.com/dir/other.html Failure Different host
http://example.com/dir/other.html Failure Different host (exact match required)
http://v2.www.example.com/dir/other.html Failure Different host (exact match required)
http://www.example.com:80/dir/other.html Depends Port explicit. Depends on implementation in browser.
Unlike other browsers, Internet Explorer does not include the port in the calculation of the origin, using the Security Zone in its place.
So, for example, your JavaScript cannot download anything from (aka, make an HTTP request to) a web server other than the server it originated from. This is exactly why you cannot make XmlHttpRequests (aka AJAX) to other domains.
CORS is one way the server at the other end (not the client code in the browser) can relax the same-origin policy.
The CORS standard works by adding new HTTP headers which allow servers to serve resources to permitted origin domains. Browsers support these headers and respect the restrictions they establish.
Example: Say your site is http://my-cool-site.com and, you have a third party API at domain http://third-party-site.com, which you can access via AJAX.
And let's assume that a page from your server my-cool-site.com made a request to third-party-site.com. Normally, users browser will decline AJAX calls to any other site other than your own domain/subdomain per the Same-Origin Security Policy. But if the browser and the third party server supports CORS, following things happen:
Browser will send and Origin HTTP header to third-party-site.com
Origin: http://my-cool-site.com
If the third party server accepts requests from your domain, it will respond with an Access-Control-Allow-Origin HTTP header:
Access-Control-Allow-Origin: http://my-cool-site.com
To allow all domains, third party server can send this header:
Access-Control-Allow-Origin: *
If your site is not allowed, browser will throw an error.
If the client's have fairly modern browsers that support CORS, and your third party server supports CORS as well, CORS can be useful to you.
In some obsolete browsers (IE8, for instance), you have to use a Microsoft-specific XDomainRequest object instead of XMLHttpRequest to make a call that will work correctly with CORS; this outdated now, all modern browsers (including from Microsoft) handle CORS in XMLHttpRequest instead. But if you need to support obsolete browsers, this page describes it:
To make a CORS request you simply use XMLHttpRequest in Firefox 3.5+, Safari 4+ and Chrome and XDomainRequest object in IE8+. When using XMLHttpRequest object, if the browser sees that you are trying to make a cross-domain request it will seamlessly trigger CORS behaviour.
Here is a javascript function that helps you create a cross browser CORS object.
function createCORSRequest(method, url){
var xhr = new XMLHttpRequest();
if ("withCredentials" in xhr){
// XHR has 'withCredentials' property only if it supports CORS
xhr.open(method, url, true);
} else if (typeof XDomainRequest != "undefined"){ // if IE use XDR
xhr = new XDomainRequest();
xhr.open(method, url);
} else {
xhr = null;
}
return xhr;
}
Again, that's only necessary for obsolete browsers.
The above reasons are why you cannot use Amazon's web services from your script. And Amazon server will only allow downloading their JavaScript files to pages served from selected domains.
To answer your numbered questions:
- The file will be downloaded by the browser if it is in the same origin.
- If it is not in the same origin, the file will be downloaded if a CORS request succeeds.
- Or otherwise, downloading the script will fail.
- If the download succeeds, the content of the JavaScript file will be loaded to browser's memory, interpreted, and executed.
See description on CORS to understand.
Best Answer
No, it's about bar.com controlling use of its content.
Yup. And if you do, and the people at bar.com notice and care, they disallow requests from your server. You move it, they disallow the new one. Whack-a-mole time. But painful as that game of whack-a-mole is, it's a lot less painful than if the requests come directly from each individual user of foo.com, from their desktop.
Having foo.com enforce what foo.com can do doesn't make any sense. foo.com already enforces what foo.com can do, because it's foo.com that serves foo.com's content and scripts.