Update If you like this, continue reading Cross-domain Ajax via Flash
This week's Weekly Web Hack is the first in a four part series on cross-domain scripting. Here I'll review the nature of the same-domain policy, and how this hinders next-generation web app development. I'll also go over existing "solutions" to set the stage for the upcoming articles.
First, lets talk about the problem for a bit. It goes by the name same origin policy, and this explanation from mozilla.org is typical:
This means that it is largely impossible to load scripts from one domain into another. For example, the following are prohibited:
The same-origin policy exists to prevent malicious use of resources. If there were no rules governing cross-domain script access, it would be trivial to wreak all manner of havoc on unsuspecting users. It would be easy, for example, for a malicious website to grab your session information to another site and execute actions on your behalf.
For one example, consider this:
And that's just one example. A more insidious plot would involve a malicious third party using your browser to spider your company's intranet, leaking classified information with you as the unwitting accomplice!
Well, yes and no. The same origin policy is good at keeping scenarios like the aforementioned from occurring, but it's not the only way, and it has some significant drawbacks. For example, consider Yahoo!'s variety of web services. The Yahoo! Developer Network site openly advocates using their services in building web applications. However, without the proper setup, an unknowing web developer is destined to run face first into the same-origin policy.
Clearly the developer's server isn't in the yahooapis.com subdomain where data will be queried from, so how can Ajax requests be issued to their web servers?
To Yahoo!'s credit, they're at-the-ready to explain how to use a web proxy for cross-domain XMLHttpRequest calls. Incidentally, this procedure of using your own web server as an intermediary to third-party web services is often the first one new developers will find, and it's also potentially the most costly.
Due to the server requirement, this is not always a desirable option. Plus, if you're going to invest in the requisite infrastructure to set up a scalable, performant web-proxy, then you'll probably end up implementing some server-side caching to cut down on total bandwidth. And at that point, you're really providing enough of a service that adding your own value-added features (data aggregation for example) makes sense. Scope creep anyone?
Another problem is the same-IP funnel. If the remote site isn't actively supporting third-party development against their public APIs, they may simply block your server's IP from incoming requests when it becomes a noticeable fraction of their total traffic. Changing your server's IP address may be costly, difficult, or even impossible in some circumstances.
Gmail was susceptible to this kind of cross-domain scripting, but closed the hole over a year ago, shortly after it was discovered. Jeremiah Grossman has an excellent writeup of these advanced web attack techniques using Gmail.
Clearly the state of cross-domain scripting is not to the advantage of the aspiring web developer. Although the cross-domain policy in place today keeps bad things from happening, it is much too restrictive to promote (or even allow) the next-generation of web-applications to be developed.
Over the course of the next few weekly web hacks, I'll go over some lesser known and never-before-seen solutions to enabling cross-domain Ajax. Stay tuned!
Hope this helps. As always, I'll be happy to answer any questions.
Got something to say?