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