Flash Player tightens the security model for client-server communication

In the most recent version of Flash ( released in mid April, Adobe has changed the rules on how .SWF files are allowed to talk back to the server. The main motivation appears to be the old model did not give the host enough control over the abilities an .SWF aplication. The new model allows for tighter security and the improved security is there by default.

Side-effects being that if you used to rely on:
- doing HTTP requests (with loadVars for example).
- having .SWF-files load other .SWF-files.
- loading data using for example XML-files or AMF-PHP or SWX.
- socket based communication

...you might be in trouble now as the masses slowly update their Flash Players. Unless you are up to speed with the new policy conventions that is.

Go through this document (split into 7 pages) to get the full details:

To find out which version of the flash plugin you have installed, visit:

To summarize, there are two classes of rulesets:
1. Url Policies (crossdomain.xml)
2. Socket Policies (port 843)


Url Policies (/crossdomain.xml)

Regulates which regular HTTP requests via an XML file, typically placed in your server's root folder. It should contain two things: The Cross-Domain Policy which tells your .SWF what it can do, and the new Meta Policy (the <site-control> tag) which tells your .SWF which Cross Domain Policies are allowed...

Starting in the Meta Policy is mandatory, and if you don't have it your Cross Domain Policies will be ignored.


<site-control permitted-cross-domain-policies="master-only"/>
<!-- Top level domain name -->
<allow-access-from domain="yourdomain.com" secure="false"/>
<allow-access-from domain="yourdomain.com" to-ports="80,443" />
<allow-http-request-headers-from domain="yourdomain.com" headers="*" />

You can add multiple domains, and you can also add stars to cover a range of subdomains. domain="*" is valid as well if you want to give the .SWF full access

Example 2:

<site-control permitted-cross-domain-policies="master-only"/>
<!-- Top level domain -->
<allow-access-from domain="yourdomain.com" secure="false"/>
<allow-access-from domain="yourdomain.com" to-ports="80,443" />
<allow-http-request-headers-from domain="yourdomain.com" headers="*" />
<!-- Subdomains -->
<allow-access-from domain="*.yourdomain.com" secure="false"/>
<allow-access-from domain="*.yourdomain.com" to-ports="80,443" />
<allow-http-request-headers-from domain="*.yourdomain.com" headers="*" />

If your .SWF loads data from a remote server, the remote server might need to have a permissive /crossdomain.xml as well (http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403185&slice...).


Socket Policies (port 843)

If your application communicates using sockets, the crossdomain.xml does not cut it.

In my case I was using the Actionscript 2.0 version of the XIFF library which lets you build chat rooms using on the XMPP instant messaging protocol with an XMPP server like Openfire as backend.

In a situation like this, Adobe wants you to serve a similar XML structure as crossdomain.xml, but on port 843 with a specialized service (see below). This is the so called Socket master policy file.


<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for xmlsocket://socks.example.com -->
<!-- This is a master socket policy file -->
<!-- No other socket policies on the host will be permitted -->
<site-control permitted-cross-domain-policies="master-only"/>
<!-- Instead of setting to-ports="*", you can use ranges and commas -->
<!-- This will allow access to ports 123, 456, 457 and 458 -->
<!-- allow-access-from domain="yourdomain.com" to-ports="123,456-458" / -->
<allow-access-from domain="yourdomain.com" to-ports="*" />

This information needs to be served by a socket policy file server on port 843 though. Adobe provides a reference implementation in Python and Perl. I successfully got XIFF working using this method.