A site dedicated to crossdomain.xml

I just stumbled on a simple little site called crossdomainxml.org that is devoted to the hugely useful yet somewhat shy and strangely mysterious crossdomain.xml file.

In the early days of Flash, the security sandbox was quite lax and sandbox security errors were almost unheard of. With each new version, however, Adobe (ok, ok, Macromedia) heightened the security of the player to address XSS (cross-site scripting) issues and other security concerns (like the hijacking of trusted network data from untrusted networks).

Instead of blocking data transfer between domains fully as Ajax does, however, Macromedia implemented the crossdomain.xml file so that server administrators can grant access to the data on their servers to either a list of selected domains or to any domain. Among other things, this makes it possible to consume web services from various public web APIs without using a server-side proxy but it does mean that the server has to implement either an open crossdomain.xml file (use the allow-access-from domain="*" rule) or that the server administrator has to add your domain to the list of allowed domains in the crossdomain.xml file. But which public services do this? This is where crossdomainxml.org comes in.

The site currently lists four public web service providers that have implemented open crossdomain.xml files. These are Yahoo!, YouTube, Flickr, and Amazon. It also links to several articles with more information on crossdomain.xml files.

I'm glad to see high-profile services implementing the crossdomain.xml file as it means that Flash developers can play with these services easily and create fun mashups without writing server-side code. For real-world applications, of course, you should be consuming web services on the server and exposing the data to your Flash/Flex client through an efficient protocol such as Flash Remoting (AMF).

Consuming web services on the server as several advantages. Most importantly, there's the security advantage. Always remember never to put any sensitive information inside your public-facing SWF files. For example, I cringe whenever I see ActionScript that contains database connection information -- you might as well not use a password if you're going to do that. This also applies to any private keys you may be using to access a web service. Don't forget that anyone can disassemble a SWF to get at any information that's included in it. At the very least, they can use your key to make API requests and use up your quota. If the web service is one that you are paying for, this could be an expensive mistake to make! Consuming services on the server also means that you can implement redundancies in case the public web service becomes available (e.g., use a local cache.)

Comments