About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.

The Dangers of Cross-Domain Ajax with Flash

In a previous blog post, I discussed the insecurity of cross-domain Ajax. In the comments, I referenced a cross-domain Ajax with Flash demonstration created by Julien Couvreur:

My initial observation leads me to believe that the target site has to allow these requests in a file called crossdomain.xml.

Julien replied:

You are correct: cross-site requests in Flash require an explicit opt-in from the server, using crossdomain.xml. That file not only needs to be there, it also needs to identify which foreign domains are allowed to do cross-site requests (which is '*', a wildcard, in most public web sites I've seen so far, like Yahoo, Amazon, etc.).

Yikes! Can you spot the problem? I certainly did. If a web site allows cross-domain Ajax requests initiated from anywhere, it is vulnerable to exactly the types of attacks I was describing. I immediately searched Google for some examples:


One of the first results was http://flickr.com/crossdomain.xml. (It no longer exists; keep reading.)

    <allow-access-from domain="*"/> 

Oh no! Not Flickr! Because of this policy, I knew I could make any user of Flickr perform any action of my choosing. As a user of Flickr, I knew I could just as easily be the victim.

One of the people commenting on my post seemed to have a difficult time grasping the concept, so I doubted my ability to describe the problem clearly. Also, because my Flash and JavaScript skills are poor, I knew it would take me a while to develop an exploit. (Exploits tend to be much clearer than explanations.) So, I emailed Julien Couvreur (the author of the Flash demonstration I mentioned), and he graciously agreed to help me develop an exploit to demonstrate the risk. At the same time, I contacted Cal Henderson and tried to explain the vulnerability over IM.

Luckily, Cal understood the vulnerability immediately, so Julien's exploit was unnecessary. However, we still collaborated to create an exploit that was similar to the Myspace worm. Users would automatically add you as a friend (and family, for good measure). Of course, the exploit worked, so the vulnerability was verified. Julien and I plan to write a paper on this particular attack in the near future, primarily to help others avoid making the same mistake.

Flickr has since isolated their API to a separate domain in order to resolve this particular problem. I haven't spent time researching the potential risks of this approach, specifically CSRF attacks that target an API, but at least the primary and obvious problem has been fixed. In addition, Cal was notified on the 11th of August and fixed the vulnerability on the 23rd. In less than two weeks, he had implemented a fix that required changing the endpoint of all API calls. I wish all vendors respected their customers this much. (Amazon, are you listening?)

If you have a public API and want to allow cross-domain Ajax requests with Flash, be sure to use a separate domain. If the user interface and API operate in the same domain, there's almost no limit to what an attacker can do.

About this post

The Dangers of Cross-Domain Ajax with Flash was posted on Sun, 24 Sep 2006. If you liked it, follow me on Twitter or share:


1.Zak Greant said:

Hey Chris,

[announcement type="public service"]

This (among other things) is one of the reasons that we really need a Free Software/Open Source Flash player.

Thankfully, Rob Savoye and crew are working on Gnash, a Free Software Flash player that includes a security manager.

Visit http://www.gnu.org/software/gnash/ to learn more.

You might want to chat with Rob a bit to learn more about the security implications of Flash movies - drop me a line and I will pass on his email address.




Sun, 24 Sep 2006 at 19:16:39 GMT Link

2.James Benson said:

Very interesting stuff!

Mon, 25 Sep 2006 at 18:58:00 GMT Link

3.Roderick Divilbiss said:

Such a simple, yet potentially damaging vector. I am dismayed that so few people have bothered to Digg this.

Mon, 25 Sep 2006 at 23:52:09 GMT Link

4.Ivan said:

Sadly, if Chris wanted attention, he should have disclosed this information before Flickr had a chance to fix the problem.

I'm glad he chose to wait.

Tue, 26 Sep 2006 at 01:04:57 GMT Link

5.Chris Shiflett said:

Julien has now written about this:


Tue, 26 Sep 2006 at 01:07:12 GMT Link

7.tyler said:

I'm not sure you are right about this. the cross-domain file alows flash to read files from remote servers, this has nothing to do with writing files or making calls to that domain. You us a cross-domain file in a web service so that flash can read it's xml files. I'm not sure about how "there is no limit to what an attacker can do". I could be wrong about this but I wont disagree that it is a good thing to separate your webservices domain from your public site.

Thu, 28 Sep 2006 at 14:41:58 GMT Link

8.Chris Shiflett said:

I'm sure I'm right about this. The exploit worked. That's an objective observation.

Thu, 28 Sep 2006 at 17:45:02 GMT Link

9.Chris Shiflett said:

YouTube is vulnerable:


Fri, 29 Sep 2006 at 23:24:21 GMT Link

10.Chris Shiflett said:

YouTube has been notified.

Fri, 29 Sep 2006 at 23:34:25 GMT Link

11.Chris Shiflett said:

MusicBrainz is also vulnerable:


They have been notified.

Fri, 29 Sep 2006 at 23:37:57 GMT Link

12.strk said:

could you explain to me again what is possible that is not with normal HTTP, when you use a crossdomain.xml allowing full access from anywhere ?

I seem unable to grasp the concept, and the whole 'crossdomain.xml' thing seems only based on control

over the player, which can only be assumed by making user NO OTHER PLAYER then the uncorrupted MM one exists.

Mon, 20 Nov 2006 at 15:46:52 GMT Link

13.Renaun Erickson said:

This does not stop security issues you can do the same things with HTTP api calls. The security lies in the API and the trust apps them selves. These large services if they want to, can open up API's for people to make mashups.

Shutting down the crossdomain.xml doesn't change the "I knew I could make any user of Flickr perform any action of my choosing. As a user of Flickr, I knew I could easily be the victim in such a scenario."

You could do the same thing with a scripting language based app that would do the same thing. These are open API's by Flickr so people can build apps on top of their service.

Wed, 13 Dec 2006 at 19:09:20 GMT Link

14.Renaun Erickson said:

I think I was still confused with my first statement. I am trying to put it all together. It finally hit me that I was meshing the API and the normal main site token authentication together.

"If you have a public API and want to allow cross-domain Ajax requests with Flash, be sure to use a separate domain. If the user interface and API operate in the same domain, there's almost no limit to what an attacker can do."

That helped clear it up.

Wed, 13 Dec 2006 at 21:50:33 GMT Link

15.Chris Shiflett said:

Renaun, hope it makes sense now. :-)

Thu, 14 Dec 2006 at 21:47:42 GMT Link

16.Chris Shiflett said:

YouTube is no longer vulnerable.

Thu, 14 Dec 2006 at 21:48:20 GMT Link

17.Good Education and Awareness may help said:

Note sure if this is already obvious to everyone, but it seems that "PowerSDK Software Corp." has registered the domain "http://www.crossdomainxml.org/". I sure hope that Yahoo and Flickr (Google too?) will keep their sites open for external developers. Cross domain access is truely useful when the "big sites" opt in. I just hope we don't lose it. Will it be possible for crossdomainxml.org to be kept up to date with policy file location information and status?

Sat, 30 Dec 2006 at 14:32:01 GMT Link

18.Chris Shiflett said:

YouTube has an open policy again, isolated to a subdomain like Flickr:


Wed, 27 Feb 2008 at 22:21:08 GMT Link

19.Kyle Simpson said:

I've got a project called 'flXHR' http://flxhr.flensed.com/ which is a flash+javascript direct re-implementation of the native XHR api, but using an invisible flash object to allow cross-domain requests. Since it's API is identical, it's an easy drop-in replacement for native XHR, and can thus be used very easily with any existing code or JS frameworks (like jQuery, Dojo, etc).

Since it uses flash (specificaly 9.0.124+), it utilizes the newest, strongest implementation of Adobe's cross domain server opt-in policy to authorize such communication, which makes the communication using flXHR inherently more secure, more efficient, and less hacky than many of the other common cross-domain workarounds available right now.

In addition, by centering on the native XHR API, flXHR becomes an effective "future-proof" drop-in solution until such time as browsers extend those API's to allow for native cross-domain-safe communication.

Mon, 20 Apr 2009 at 14:14:41 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.