Tiffany B. Brown

10 October 2011

HTML5 for AS3 Developers: cross-domain.xml and Cross-Origin Resource Sharing

This is the second post in an occasional series designed to bridge the gap between ActionScript 3.0 and emerging front-end technologies.

Flash, like JavaScript, more-or-less adheres to a same-origin policy by default. Under a same-origin policy, requests for data must come from the same scheme, hostname, and port. If http://foo.example tries to request data from http://bar.example, the request will usually fail.

Same-origin policies are designed to prevent the unauthorized leakage of data to a third-party server. Without it, a script or SWF hosted on could read data hosted on and send it to This kind of cross-domain activity could be used to exploit cookie and authentication data. It's clearly a bad thing.

Recent browsers have safeguarded against these kinds of cross-site scripting exploits by preventing JavaScript from making cross-origin requests. XMLHttpRequest, for example, will throw a security exception if you attempt a cross-origin request.

Flash, meanwhile has long supported a means for enabling cross-origin requests: the policy file. The policy file is a way of white-listing requests for data or credentials from specific origins. It lives on the server from which you are requesting data, and gives the Flash player a "yay" or "nay" when asked whether the request from a specific origin should be allowed to complete.

Cross-origin restrictions, though necessary, are also quite limiting. You can't (or couldn't), for example, request data for a mash-up using XMLHttpRequest. Though there are workarounds — using dynamic script insertion, or using the document.domain — those workarounds also leave the DOM vulnerable to cross-site scripting.

To to mitigate the dangers of cross-site scripting while still enabling it, the W3C is developing the Cross-Origin Resource Sharing (CORS) specification. It functions similarly to Flash’s cross-domain policy file, but uses HTTP headers instead of an XML configuration file.

CORS request headers are automatically generated by conforming browsers when a script attempts a cross-domain request. Response headers must be set in the server's configuration file, or dynamically per URL using a server-side language.

Let’s compare a sample cross-domain.xml file to how we'd achieve the same thing using CORS.

Cross-origin requests from Flash

To use the domains from our example above, if made a request to data hosted on, would need to permit the request by including it in its policy file. For example:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "">
    <allow-access-from domain=""/>

This file must be stored in the web root of It explicitly permits — and permits only — to make requests for its data (from within a Flash movie).

Cross-origin requests from the DOM

To reuse our example from above, let’s use XMLHttpRequest to make a request from to

var xhr, onLoadHandler

onLoadHandler = function(event){
     alert('It is done!');

xhr = new XMLHttpRequest();'GET','');
xhr.onload = onLoadHandler;

It looks just like a regular XHR request, except for the fact that we're requesting data from another origin. Let's take a look at our headers.

Accept-Encoding:gzip, deflate
User-Agent: Awesome/9.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) FantasticEngine/8889876 Awesome Browser/9.0

Notice that our headers include Origin: responds with the following headers.

Date:Mon, 26 Sep 2011 04:44:50 GMT
Keep-Alive:timeout=5, max=100

Here we see that an Access-Control-Allow-Origin response header is returned by the server. Like allow-access-from, it indicates which domain(s) are allowed to make requests. Here, we want to know whether is allowed to request data. It is, so the request will be completed.

Acceptable values for Access-Control-Allow-Origin include an origin (scheme + host + port), a comma-separated list of origins†, or a wildcard (*). As with cross-domain.xml, if the value of Access-Control-Allow-Origin had instead been, the request would have failed. Using a wildcard allows requests from any domain.

Of course, both specifications are more complex than what I have covered here. These examples illustrate how to enable a basic cross-origin request. It is also possible with both CORS and Flash to permit or exclude custom headers. And in the case of CORS, it is possible to use methods such as PUT or DELETE if the user agent supports it.

Opera Opera Mini Opera Mobile IE Firefox Chrome Safari iOS Safari Android WebKit

11.60+ no no 8.0+ 4.0+ 5.0+ 4.0+ 3.2+ 2.1+

Browser support for Cross-Origin Resource Sharing as of 10 January 2012

Learn more

† Most browsers do not yet support multiple origin values. The specification is also a working draft, and subject to change.