How Bad Crossdomain Policies Expose Protected Data to Malicious Applications

The web’s success has been partially due to the sandbox it provides users. Users do not generally have to entirely trust every website they visit because malicious web sites should be sandboxed from doing the user harm. One way that web sites are sandboxed is through a same-origin policy. By default any code that runs inside a web browser can only access data from the domain in which the code originated from. So if code (JavaScript, Flash, etc) loads from the domain then it can’t access data on the domain. The code may be able to make requests to but the code from shouldn’t be able to read or access the results of those requests.

Since Rich Internet Applications built with Flex, Silverlight, etc usually try to do more on the client side, for example mash-up data from multiple sites, the same-origin policy presents a problem.

In most cases Flash Player sticks with the typical browser sandbox concepts. But there are a few places where it goes outside this boundary such as with microphone and webcam access. Another area is by allowing opt-in to cross-domain communication bypassing the browser’s regular same-origin policy. Other plugins such as Silverlight and JavaFX also do this. This cross-domain capability is powerful but also very dangerous. The primary reason it’s dangerous is that a malicious application can potentially make requests on behalf of the user and access data from domains that the application didn’t originate from. To protect against these types of attacks Flash Player and other plugins have implemented a cross-domain policy system. This policy system is one of the most misunderstood aspects of web security.

To illustrate the problem I’ve create a few demos. Let’s say that I’m building an application that will fetch some data from the site.

Here’s that application on – open it in a new window.

The application correctly pulled the data from the site but in order to allow the request I blindly put a crossdomain.xml policy file on that looks like this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "">
    <site-control permitted-cross-domain-policies="master-only"/>
    <allow-access-from domain="*"/>

What this policy file does is instruct Flash Player to allow requests from any website to get around the same-origin policy and make requests to – on behalf of the user. Sounds harmless, right? At this point it is, as long as all of the data on is publicly available data. But let’s suppose that not all of the data should be publicly available. Perhaps I’m protecting access to some data though cookie authentication or HTTP basic authentication. In this case I am (for the purpose of the demo).

See the protected data by opening up using “username” and “password” (without quotes) for the user name and password.

Now imagine that someone starts posting Twitter links (obfuscated through a URL shortener) phishing for people to open a malicious application (open it in a new window – I promise it doesn’t do anything bad).

So let’s recap… There is a protected resource that only you should be able to see in your browser. Other applications should NOT be able to see that data. But a malicious application was able to load that same data and do whatever it wants with it. Scary.

Here’s how it works… The malicious application requests the protected page. It was able to make the request because you were authenticated already. And the malicious application can now read the data contained in the page and do whatever it wants with it (probably send it back to a server somewhere).

OK. Now do you understand why crossdomain.xml policy files are dangerous? Imagine if Facebook, MySpace, or YouTube had a misconfigured policy file on their servers! Well they have – but they’ve since been fixed. Imagine if your bank or a corporate intranet had a misconfigured policy file. There are some very serious ramifications to these types of attacks.

There are also some great uses of crossdomain policy files. For instance, has an open crossdomain.xml policy file. This allows applications loaded from anywhere to access Flickr data and it’s safe because doesn’t use cookies or basic auth – they use web service tokens, which are not automatically transmitted by the browser and are only known to the application that performed the authentication.

I often hear from Flex / Flash developers that when they run into security sandbox issues the first thing they try is to open things up with a global (i.e. “*”) policy file. I hope this article discourages that practice. Developers should understand why the security error is happening and consider alternatives before blindly opening up their website to the possible attacks. One alternative is to leverage a server proxy. A server proxy can be configured so that an application doesn’t violate the same-origin policy. For instance, if an application on needs data from then a proxy can be configured such that requests to are forwarded on the server to the site. This helps avoid attacks because users’ cookies (or basic auth tokens) will not be sent to since all requests are actually being made to the site. But be careful not to expose intranet servers through proxies. Here is a sample Apache config for setting up a forward proxy:

  ProxyRemote  /bar/*
  ProxyPass /bar
  ProxyPassReverse /bar

BlazeDS also includes a proxy service.

If you really need to use a crossdomain policy file then be very careful! NEVER put a crossdomain policy file on a site that uses cookie or basic auth and NEVER put a crossdomain policy file on an intranet site – unless you really know what you are doing. To learn how to safely use crossdomain policy files here are some great resources:

I hope this helps create better understanding of web security. Please let me know if you have any questions.

  • skiN

    ” If you really need to use a crossdomain policy file then be very careful! NEVER put a crossdomain policy file on a site that uses cookie or basic auth “… But the site was able to access the secured data because the server firststepsinflex had a wrong cross-domain policy. How will it be harmful if the cross-domain policy was written not to give access to requests from all domains?

  • Ricardo Santos

    Thank you for your article, I always had this doubt that maybe you can you explain, what keeps a malicious developer from finding a way to deliver a fake crossdomain.xml to the client or even hacking it to simply ignore any crossdomain file and access any data from anywhere?

    From a non Flex developer point of view, crossdomain.xml only relation to the server is that it “lays there”. To my knowledge, it isn’t configured together with any of the services provided there, so to the server it is just a normal file it serves via HTTP like any other, if it is a server policy file, the server knows nothing about that.

    I mean, it would all make sense if for instance you would show me some web server configuration that would load that file and respect the policies set there. If those are security validations made on the client side then for me there is no security at all.

    I would appreciate if someone can clear this out for me, as this always felt really wrong for me and I expect that there is something that I’m passing out on.

  • Hi skiN,

    I could have limited the crossdomain requests on to only be allowed to come from which would have made things more secure. But in that case I’m putting 100% trust in to not host any malicious applications. Since runs WordPress and a numer of other applications which could potentially allow an attacker to put a malicious application on it’s usually easier to just follow my two rules than to place that amount of trust in another site.


  • Hi Ricardo,

    You are right that crossdomain.xml files do not actually protect data on a server. They only provide a way for the browser to bypass the same-origin policy. There were some attacks that utilized fake crossdomain policy files. For instance if a site allowed anyone to upload files to it then an attacker could easily inject custom policy that would open the site to attacks. This type of attack was blocked with the introduction of master policies. Read more about those in the articles I link to above.


  • Pingback: Apukeittiƶ.fi » Blog Archive » Crossdomain.xml ja turvallisuus()

  • Hi James,

    Thanks for your reply!

    So correct me if I’m wrong, but shouldn’t this work the opposite way and the client application have a list of allowed domains it can retrieve data from? I just fail to see the profit in having a client specific setting hanging on a server that knows “nothing” about the client.

    This has been a topic of discussion between me and Flex developers for a while, as I don’t like to pollute my servers with several crossdomain.xml files across all of the back-end domains I use, serving several Flash front-ends from several other different domains (having to pre-set them all on separate locations). Of course I could just have an alias serving a allow from all site, but I feel that then it would be plain stupid and it would raise the issues you pointed out here.


  • Hi Ricardo,

    Crossdomain.xml is really just a way for a server admin to opt-in to telling the browser to allow cross- domain requests to their server. It doesn’t create any new security. It selectively reduces the existing security provided by the browser. Proxies on the other-hand don’t change anything about the client-side security and should be a much preferred choice over crossdomain.xml files.


  • Hi,

    Great article and discussion, but I feel like I am still missing something.

    Your entire attack vector is based on “you are already authenticated” fact, but shouldn’t cookies follow the server origin policy? That is, the session cookie should only be sent to original server it came from, no? The cross domain policy helps with access to other resources to be pulled in, but the outgoing request to those other domains shouldn’t really contain the source cookie from domain, as I understand the HTTP specs…

    Can you shed some light on this?

  • Follow-up comment to my own comment.

    After spending more time thinking about it, I think I understand now. The malicious app is making a request to the original resource on . Browser sends a cookie there, because that is where the cookie originated.

    So, I am actually in agreement with Ricardo that crossdomain policy is a weak link in this approach. Can you talk a bit (perhaps in a next blog) about alternatives to securing BlazeDS app via web-service tokens, rather than cookie/basic auth?

  • Hi Adi R,

    It’s pretty easy to base authentication off of a database table that maps tokens to users. That’s what I’ve done in the past. It gets away from cookies / basic auth but it does require the user to reauthenticate every time they use the app (unless you use a Local Shared Object).


  • buddy

    Hi James,

    I m workin on application which works well with localhost, i m using JBoss. But if i run jboss for all ip’s
    and run my application. It shows Sandbox violation error.
    I used everything possible using crossdomain.xml, but still there is a error.

    Plz any help wud be appreciated…

    Thank U

  • Found this post when trying to figure out the 404 error with crossdomain.xml on wordpress. Thanks for the great explanation, and the post gave us a lot to think about!