Monday, September 10th, 2007

CrossSafe: Secure Cross Domain JSON

Category: Security

Kris Zyp has just released a beta version of CrossSafe, a tool that provides secure cross domain JSON requests and partially implements the JSONRequest specification (the get and cancel methods).

You can also see a demonstration where you can pull information from Yahoo’s web services, Brad Neuberg’s transclusion web service, and a JSON object database at, while staying secure in the midst of an attack from a malicious script. CrossSafe uses a technique for securing communication that is similiar to the Subspace approach from a recent Ajaxian post, that utilizes existing standards and is much more efficient and robust than the fragment identifier messaging.

Kris would also like to know if anyone can thwart the security in CrossSafe. It would be great if some good hackers could see if there is any holes, so we can really secure this software, and have a quality tool for the community for building secure mashups. From the test page there is a text box for entering in your own URLs to make it easier to stage attack attempts.

Posted by Dion Almaer at 10:00 am

3.9 rating from 28 votes


Comments feed TrackBack URI

This is very interesting. The recent offline version of PassPack uses scriptInject to inject json directly in a script tag. But we have that option because we trust the script (it’s coming from our server).

The CrossSafe approach is interesting because it should permit the exchange of data with server that you don’t trust before.

Good work. I’ll have fun to try and break it. :)

Comment by Francesco — September 10, 2007

I like the idea to secure cross-domain requests, but feel that a proxy-approach is better suited for corporate environments, as it allows better governance. So although I’m really excited about CrossSafe – provided it can’t be hacked – I wouldn’t recommend it for every situation.

Comment by Jep Castelein - Backbase — September 10, 2007

Jep- Yes, CrossSafe is not the answer for every problem. There are a number of considerations. Performance due to network topology should be consideration. If the foreign domain server is significantly closer (latency and bandwidth wise) to the origin server than the browser and few requests are made, than the proxying is probably faster since the setup cost of CrossSafe would not be worth the benefits. On the otherhand if the foreign domain is roughly as close to the browser as the origin server and there is a potential for a number for JSON requests, than CrossSafe can offer significant performance benefit.
I am not exactly sure what you mean by governance and how that impacts the corporate environment unless you are referring to being able to do data manipulation or size limiting on the server. I don’t think this is necessarily always a bad solution for the corporate environment. If normal proxying is being done, I don’t see the disadvantage of CrossSafe for governance. A potential benefit in the corporate environment and otherwise is reduction of load induced by proxied requests.
Another consideration is implementation limitations. CrossSafe does have it’s limitation, like requiring certain DNS host name configurations that may eliminate it as a choice. Also, if a proxying solution is already in place, it is easy to continue to using it. If not however, CrossSafe can eliminate the cost of developing a proxy solution.

Comment by Kris Zyp — September 10, 2007

Now, we just need this, TrimJunction, and Jester to come together to provide a single unified Framework for developing JavaScript applications.

Comment by Justin Meyer — September 10, 2007

I think I might have something even better in the works than this combination. I really like Jester, and have chatted with them, and would be glad to help integrate CrossSafe into Jester, but keep your eye out for Persevere and Jsponic for complete JS application development.

Comment by Kris Zyp — September 10, 2007

Really interesting Idea. But I would wait for release with label “Stable”. Although I also will give a try. At least is move in the right direction.

Comment by Nik Chankov — September 11, 2007

First, a little background. I’m working on an online IDE which would allow developers to build and sell complete applications. I don’t really care WHAT javascript framework makes it. I just care about when. That being said …

After reading about Persevere and Jsponic, I’m not sure they are ‘better’ for providing a framework for application development than TrimJunction. Persevere and Jsponic provide a very nice (and probably superior) way of transferring data from client to server and back.
However, TrimJunction is a complete ‘framework’. It’s MVC based and has almost all of rail’s functionality built in. It works hard at being easy to install and understand. We’ve made a OnLamp style cookbook demo:

TrimJunction has a ‘featured’ protocol for transporting and syncing data; however, that could easily be replaced by Persevere or Jester.

I’d really like to see the community centralize on 1 javascript Framework. Features?

Very easy to build basic CRUD applications and mashups.

Server / Data transportation layer agnostic. If you have REST services, use Jester, if you are running Jsponic, use presevere. If you have a SOAP service, use something else. But, you should still be able to call Task.find(1)

I actually started writing a lot more things, but these are the only 2 important ones. A framework will only be successful if any developer can use it. And, it will only be successful if most people don’t have to change their infustructure to handle it.

Btw, correct me if I’m wrong about what Persevere and Jsponic provide. They don’t have the best explanation. Which gets back to making things easy …

Comment by Justin Meyer — September 11, 2007

Nik – What you don’t want to completely trust all your private data to my brand new beta software? :). Yes, waiting for a stable release is very reasonable. One of my main intentions with this posting was to see if anyone could find any security flaws, so I could confidently put a stable release out there. None reported so far…
Justin – Persevere and Jsponic don’t have good explanations because they are not really released yet! Yes, I am sure TrimJunction does a number of things that Persevere doesn’t. Persevere is persistent object mapping framework, it doesn’t enforce an MVC approach. Also, to clarify, Jester does not exactly follow REST protocol, Persevere is every bit as RESTful, and it uses a JSON format that is readily available ( What Jester excels at is following the Rails/ActiveRecord pattern. If you are Rails developer, you need to go with Jester, it is a no-brainer for that, it is a fantastic replication of the ActiveRecord model and TrimJunction may be another great framework for Rails devs. On the otherhand Persevere (will) excels at following idomiatic JavaScript patterns. If you are more of a JS developer, I believe it will be a better choice. Anyway, sorry that I don’t have more information/documentation available, that is what I am currently working on so I can release it!

Comment by Kris Zyp — September 11, 2007

Is this approach Comet enabled?

Comment by Andrés Testi — September 12, 2007

Kris rocks! Congrats on getting this out and up Kris.


Comment by Brad Neuberg — September 14, 2007

So I could use this framework to get any data from any site without using a proxy? Does it have to be JSON returned? What about HTML?

Comment by Tyson — September 19, 2007

CrossSafe uses sandboxed dynamic script tag insertion, so you can only retrieve data that can be eval’ed as a JS script.

Comment by Kris Zyp — October 31, 2007

CrossSafe uses sandboxed dynamic script tag insertion, so you can only retrieve data that can be eval’ed as a JS script.

Comment by Kris Zyp — October 31, 2007

agree with justin
If you are Rails developer, you need to go with Jester, it is a no-brainer for that, it is a fantastic replication of the ActiveRecord model and TrimJunction may be another great framework for Rails devs

Comment by indiangenericialis — November 2, 2007

Leave a comment

You must be logged in to post a comment.