Mashup Standards: JSON-P vs. CORS

In part 1 of this post, I covered the JSON-P “standard” for mashups. Not so much a standard per se, but a sneaky way to share JSON code between servers by wrapping them in a ‘callback’ function… For example, if we have our raw JSON data at this URL:

http://example.com/data.js

A direct access would return the raw data dump in JSON format:

{ foo: "FOO", bar: "BAR" }

However, a JSON-P call would return a JavaScript file, that calls a ‘callback’ function with the raw data:

callback({ foo: "FOO", bar: "BAR" });

Since this is pure JavaScript, we can use it to bypass the “Same-Origin Policy” for AJAX… A typical AJAX call uses the XmlHttpRequest object, which only allows calls back to the originating server… which, of course, means true mashups are impossible. JSON-P is one of the (many) ways around this limitation.

Since JSON-P is something of a hack, many developers started looking for a more secure standard for sharing JSON and XML resources between web sites. They came up with Cross-Origin Resource Sharing, or CORS for short. Enabling CORS is as simple as passing this HTTP header in your XML/JSON resources:

Access-Control-Allow-Origin: *

Then, any website on the planet would be able to access your XML/JSON resources using the standard XmlHttpRequest object for AJAX. Despite the fact that I like where CORS is going, and see it as the future, I just cannot recommend CORS at this point.

Security

Since CORS is built on top of the XmlHttpRequest object, it has much nicer error handling. If the server is down, you can recover from the error and display a message to the user immediately. If you use JSON-P, you can’t access the HTTP error code… so you have to roll-your-own error handling. Also, since CORS is a standard, it’s pretty easy to just put a HTTP header in all your responses to enable it.

My big problem with CORS comes from the fact that it just doesn’t seem that well supported yet… Only modern browsers understand it, and cross-domain authentication seems to be a bit broken everywhere. If you wanted to get secure or personalized JSON on a mashup, your back-end applications will need to also set this HTTP header:

Access-Control-Allow-Credentials: true

And, in theory, the AJAX request will pass along your credentials, and get back personalized data. The 1.7 jQuery plug-ins works well with JSON-P and authentication, but chokes badly on CORS. Also, keep in mind that authenticated CORS is a royal pain in Internet Explorer. Your end users will have to lower their security setting for the entire mashup application in order to make authenticated requests.

Now, JSON-P isn’t great with security, either. Whereas CORS is too restrictive, JSON-P is too permissive. If you enable JSON-P, then you pass auth credentials to the back-end server with every request. This may not be a concern for public content, but if an evil web site can trick you into going to their mashup instead of your normal mashup, they can steal information with your credentials. This is call Cross-Site Request Forgery, and is a a general security problem with Web 2.0 applications… and JSON-P is one more way to take advantage of any security holes you may have.

Performance

In addition, the whole CORS process seems a bit ‘chatty.’ Whereas JSON-P requires one HTTP request to get secure data, CORS requires three requests. For example, assume we had two CORS enabled applications (app1 and app2) and we’d like to blend the data together on a mashup. Here’s the process for connecting to app1 via CORS and AJAX:

1. Pre-Flight Request: round-trip from client browser to app1 as a HTTP ‘OPTIONS’ request, to see if CORS is enabled betweenmashup and app1
2. Request: if CORS is enabled, the browser then sends a request to app1, which sends back an ‘access denied’ response.
3. Authenticated Request: if cross-origin authentication is enabled, data is sent a third time, along with the proper auth headers, and hopefully a real response comes back!

That’s three HTTP requests for CORS compared to one by JSON-P. Also, there’s a lot of magic in step 3: will it send back all the auth headers? What about cookies? There are ways to speed up the process, including a whole ton of good ideas for CORS extensions, but these appear to be currently unpopular.

Conclusion: Use JSON-P With Seatbelts

If all you care about is public content, then CORS will work fine. Also, it’s a 5-minute configuration setting on your web server… so it’s a breeze to turn on and let your users create mashups at their leisure. If you don’t create the mashups yourself, this is sufficient.

However… if you wish to do anything remotely interesting or complex, JSON-P has much more power, and fewer restrictions. But, for security reasons, on the server side I’d recommend a few safety features:

• Validate the HTTP_REFERER: only allow JSON-P requests from trusted mashup servers, to minimize request forgery.
• Make JSON-P requests read-only: don’t allow create/modify/delete through JSON-P.

But wait, isn’t it easy to spoof the HTTP referrer? Yes, an evil client can spoof the value of the referrer, but not an evil server. In order for an evil mashup to spoof the referer, he’d have to trick the innocent user to download and run a signed Applet , or something similar. This is a typical trojan horse attack, and if you fall for it, you got bigger problems that fancy AJAX attack vectors…DNS rebinding is much more dangerous, and is possible with any AJAX application: regardless of JSON-P or CORS support.

Links and Free Downloads

For those of you interested in Oracle WebCenter, I created a CrossDomainJson component that enables both CORS and JSON-P, and it includes some sample code and documentation for how to use it. It currently works with WebCenter Content, but I might expand it to include WebCenter Spaces, if I see any interest.

• Part 1: JSON-P
• Part 2: CORS
• Part 3: JSON-P vs CORS
• Free Download: CrossDomainJson for UCM 11g
• Free Download: CrossDomainJson for UCM 10g