Question

1. I don’t see how the callback function in JSONP is any different from the success callback function in AJAX.

2. Given #1, I don’t see how it is fundamentally more secure.

3. So is the only difference an artificial same-domain constraint with AJAX?

4. Why can’t AJAX just allow cross-domain requests; if this can cause a security hole, wouldn’t the attack just XSS a JSONP request?

Confused,
Max

Answer 1

An ajax call is an actual HTTP request from your client directly to a server. Ajax calls can be synchronous (blocking until they complete) or asynchronous. Because of same-origin security protections, ajax calls can only be made to the same server that the web page came from unless the target server explicitly allows a cross origin request using CORS.

JSONP calls are an interesting hack with the <script> tag that allows cross-origin communication. In a JSONP call, the client creates a script tag and puts a URL on it with an callback=xxxx query parameter on it. That script request (via the script tag insertion) is sent by the browser to the foreign server. The browser just thinks it’s requesting some javascript code. The server then creates some special javascript for the purposes of this call and in that javascript that will get executed by the browser when it’s returned, the server puts a function call to the function named in the callback=xxxx query parameter. By either defining variables of by passing data to that function, the server can communicate data back to the client. For JSONP, both client and server must cooperate on how the JSONP call works and how the data is defined. A client cannot make a JSONP call to a server that doesn’t explicitly support JSONP because the exact right type of JSONP response has to be built by the server or it won’t work.

So, the two communication methods work completely differently. Only ajax calls can be synchronous. By the nature of the <script> tag insertion, JSONP calls are always asynchronous.

In an Ajax call, the response comes back in a ajax event handler.

In a JSONP call, the response comes when the returned Javascript calls a function of yours.

In some ways, JSONP is a security hole that bypasses the cross-origin security mechanism. But, you can only call servers that explicitly choose to support a JSONP-like mechanism so if a server doesn’t want you to be able to call it cross-origin, it can prevent it by not supporting JSONP. You can’t make regular ajax calls to these other servers.

The browser makers can’t really close this loophole because if they did zillions of web pages would break that either already use JSONP or load scripts from other domains. For example, every page on the web that uses jQuery off the Google or Microsoft CDNs would break because the browser wouldn’t be allowed to download javascript from cross-origin domains.

JSONP was largely invented as a work-around to be able to make cross-origin requests. But, since JSONP requires explicit server support in order to work, it wasn’t really a security problem because a JSONP call can only be made to a server that explicitly decided to allow that type of cross origin call. JSONP is used much less now than it used to be because CORS was invented as a more elegant way to control/allow this. CORS stands for Cross Origin Resource Sharing and it provides a means for a target server to tell a web browser exactly what type of cross origin requests are allowed and even to tell it which web page domains are allowed to make such requests. It is has much finer control available than JSONP and all modern browsers now support CORS.

Here’s an example of how a cross-origin call causes problems. If you could load any arbitrary web page from any other web page or make any arbitrary ajax call, then imagine you were already logged into your webmail interface on Yahoo in so some other browser window. This means that your cookies are set to allow requests from your browser to fetch data from Yahoo. If the javascript in some other web page was allowed to make a webmail request to Yahoo (that would automatically have your cookies attached), it could then fetch all your webmail data and send it back to it’s own site. One web site could rip off all the logged-in data from any other web site. All web security would be broken.

But, the way we have it today, as long as Yahoo doesn’t support a JSONP interface that uses those same web cookies, it is safe from unauthorized JSONP requests.

Here are some other good writeups on the dangers of cross-origin ajax and why it has to be prevented:

Why the cross-domain Ajax is a security concern?

Why Cross-Domain AJAX call is not allowed?

Why are cross-domain AJAX requests labelled as a "security risk"?