Cross-domain policy files

Today I’d like to take a shot at summarizing the reasoning behind having cross-domain policy files in Flash Player, and some best practices related to implementing them.

The browser security model normally prevents web content from one domain from accessing data from another domain. This is commonly known as the “same origin policy.” Note that this policy does not prevent the displaying of HTML or media assets cross-domain, such as HTML in an IFRAME or other images, etc. This is also true in Flash Player.

So how did cross-domain policy files in Adobe Flash Player come about? The rationale is that sometimes its perfectly ok to permit cross-domain loading of data, such as when the data isn’t protected by a session-based login or a firewall, and is intended to be accessible from other websites. Currently, the only way to do this inside JavaScript is by using the <SCRIPT src=…> script importing syntax, which is inherently dangerous.


By providing a cross-domain policy file, a website can specify which parts of it should be accessible, and to content from which other websites. If a cross-domain policy file is located at the root of the website (the default location the Flash Player looks in for cross-domain policy files is “/crossdomain.xml”), then it controls access to the entire site. If it is placed in a sub-directory, it only controls access to that subdirectory and below.So if your website hosts only data intended for public consumption, isn’t behind a corporate firewall, and does not protect any data via cookies or other browser-based user authentication mechanisms, then you can deploy a policy file that permits access from “*” (anywhere) in your root folder.If you want to permit content from only certain websites to load data from a given server, then you could specify only those websites in your policy file. For example, if http://www.a.com and http://www2.a.com need to load data from http://data.a.com , then you would create a policy file at http://data.a.com/crossdomain.xml that would include “www.a.com” and “www2.a.com”, or alternatively, simply “*.a.com”. The server that is providing the data always hosts the policy file that controls access to its data. No other server can do so on its behalf. Here is an example crossdomain.xml:<?xml version=”1.0″?><!– http://www.adobe.com/crossdomain.xml –><cross-domain-policy><allow-access-from domain=”www.a.com” /><allow-access-from domain=”www2.a.com” /></cross-domain-policy>If on the other hand you want to only expose specific parts of your website to the whole world, then you can place a policy file containing “*” in the specific subdirectories that you want to expose to the world. You may also expose certain subdirectories only to content from specific servers, etc. The principle of least privilege implies that you should only expose the parts of your website that you really need to, and only to the minimum number of other websites.The general best practice for deploying policy files is to have separate servers. One, such as http://www.a.com, as a regular web server without any cross-domain policy files, and then another, one such as http://api.a.com, that hosts only data intended for public consumption and does not utilize any browser-based (i.e. cookies) user authentication mechanisms.There are many other permutations of this mechanism, that may or may not be applicable to your particular architecture.For example usage of cross-domain policy files, see: http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001085.htmlFor a detailed description of cross-domain policy file best practices, see: http://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html

7 Responses to Cross-domain policy files

  1. Saverio Trioni says:

    The interesting part is cross-domain policies on sockets. When you need tight integration within two or more hosts, and binary data, the best and hassle-free way is to put up a socket and forget about web servers etc. Flash player will ask on the same socket for policy information and then immediately start the communication.My use case is a RIA that sometimes needs to write raw data to local printers. So we put up a sort-of driver, that listens to a port for print jobs, and can be accessed by the Flex app.

  2. Joseph says:

    The usage of crossdomain.xml files to handle cross-domain security works great. I have had huge troubles accessing byte-level data over an RTMP stream from FMS2 though… crossdomain files do not help in this case. Is there any workaround whatsoever to this problem?Thanks for the informative posts!

  3. Michael says:

    We are currently looking into to start utilising crossdomain but are unable to get it to work with Firefox 2.0.0.6It works just fine in both IE 7 and Opera.Any ideas what might be wrong?

  4. @Michael:Does the situation you’re talking about involve any port other than Port 80?

  5. Przemyslaw says:

    Everything is quite clear, but this is build, using the same ports.I have a more complex example.My domain is under a ‘http’ (lets just say “http://example.mydomain.com” and points to ‘https’, where main application (Flex 2 Frontend and PHP+MySQL backend) is hold (“https://example2.2nddomain.com/app.swf”.Even if I my crossdomain policy file contains:…allow-access-from domain=”example.mydomain.com” to-ports=”80,443″ secure=”false”……allow-access-from domain=”example2.2nddomain.com/app.swf” to-ports=”80,443″ secure=”false”…it still shows me a “security sandbox violation” error. Is there any solution for that, please?

  6. Bob says:

    Hello,We run a server in our office and have swf’s running from there. We use a domain forwarded to our IP. I cant seem to get the cross domain working. Can you help?[Lucas]: Hi Bob, I don’t have much info to go on here. One thing to keep in mind is that Flash Player uses the final domain for determining all cross-domain requests, which means that if you have any forwarding set up, make sure you use the final URL you would see in the browser address bar when entering domains into crossdomain.xml or allowDomain() calls. You might also want to check out the support section here at http://www.adobe.com/support/flashplayer/

  7. Derek Tran says:

    I have a problem with the sandbox security. I am currently using asSQL to access my mySQL database without the PHP and XML as a middle man. It worked great when I was testing on my localhost server but as soon as I updated from flash 9.0.115 to 9.0.124, it stopped working and throws this error:”Error #2044: Unhandled sqlError:. text=SQL Error #0: Error #2048: Securitysandbox violation: http://localhost/index.swf cannot load data fromlocalhost:3306.”I am new to the crossdomain.xml thing and from what I understand I need to put it in the domain that we are pulling info from, but it is odd because it sees localhost and localhost:3306 (mySQL) as two different domains and I have no idea where to put the crossdomain policy file. Anyone have a clue and/or know if this will still be an issue when its on a real server (ie not localhost)???Lucas: Hi Derek, I’m not 100% certain from the description you provided but assuming that you code relies on sockets (or XMLSocket) to perform the actual load, you are running into the additional cross-domain socket restriction documented here: http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_04.html You will unfortunately face this problem with both your local instance and one deployed on a remote server.