Sandbox Your Cross Domain JSONP To Improve Security

JSONP is a very neat way to get JSON data from other domains. The concept was brought by Bob Ipolito in 2005, and today it is widely available from API providers.

The big issue about JSONP is security. If you inject an unknown script in your page, you give to the script author a potential way to read the entire page content, scripts, cookies and data.

So, if you think, like us, the cool way to build web apps today is about building services and aggregating them with external APIs in Mashups, you have a problem. How can we securely fetch these nice services available everywhere?

There is a standard coming out. Douglas Crockford is well known for preaching regularly about it. Here and there, you can also find some good posts explaining the issue and the available solutions. But, to be honest, there is nothing simple to configure and use today.

However, a few weeks ago, I found a post from Kris Zyp (Sitepen), who came with an elegant solution: By abusing the property, he found a way to exchange bigger cross domain text data between a page and its children iframes.

I jumped into the code and the test page. But... it needs a new type of cooperation from the server. This one needs to fill in the property when the resource is called.

Today JSONP is widely available, and our web app will call lots of them. To add some extra protection we found a surprisingly simple approach described below.

The objective of this post is twofold:

First, get your feedback to rapidly know if we missed something ;) and have to heartbrokenly look at a heavier approach such as gears or a server proxy.

And secondly, let know the Mashup builders that there may be another temporary reliever while waiting for a standard approach.

Demo Page

You can download the files on Github. Hereunder is how it works:

Sandbox Your JSONP Calls To Improve Security

  1. In your application page, add sandbox.js and call the function sandboxCall. An example can be found at
  2. The function sandboxCall inserts an iframe to the page. Now here's the trick: the source of the iframe will point to a domain you own. The API URL to inject is passed as a parameter. (a)
  3. The script is injected in the sandbox page. (b)
  4. The JSON is fetched from the API provider.
  5. Then, following the JSONP logic, the function callback is called. This function does a single task: it assigns the JSON text to the property.
  6. We can come back to our main page on, but can't be read as the location is at (Same Origin Policy). Now comes THE idea of Kris Zyp to read We change the location back to main page's domain. In our example we return to the page: Marko Mrdjenovič, in its jQuery implementation tries to get /robot.txt or /crossdomain.xml which are common files found in the root of web servers. Any existing local file is ok. (c)
  7. An onload event is fired in our main page. The location has been changed to a local URL.
  8. We can now access the of that iframe and read/parse the JSON.

A malicious script can only make damage to the sandbox page, which is empty and destroyed as it is loaded. And as long as you do not eval directly the text in your page but use a JSON parser that will only get JSON text and reject the rest, your main page shouldn't be hurt either. (d)


We know is a trick. It is also already used by Andrea Giammarchi and Thomas Frank. Hopefully when postMessage or another standard approach will be available, won't be necessary anymore.

It was tested on FF3, Safari3, Opera 9, IE6-7, Google Chrome and iPhone.

Too good to be true? Do you see some immediate improvement? Do you see any holes? Please, tell us.

For now, we are happy with just JSONP/GET. POST, DELETE could be done too.

A higher-level JS function could be built to use postMessage when available. If you have ideas about it, please fork the repository at

Thanks for any feedback.

Other links of interest:

Copyright © 2018 BeeBole Timesheet