The standard security model that Flash uses for checking domains against server policies for allowing cross-domain communication involves checking only that the server policy authorizes the SWF-domain (where the flXHR.swf comes from), for both communication and for headers.

However, for some complicated reasons (described in detail here), it is believed that this security authorization model is lacking in only looking at the SWF-domain, when considering that the page-domain (the domain in the address bar of your browser) can differ from the SWF-domain, in that anyone who hosts a SWF file like flXHR.swf on their domain (SWF-domain) has no control over another (possibly malicious) page linking to and using it in a different page-domain. Since flXHR.swf by necessity exposes a great deal of control to the calling page's Javascript, the page that flXHR runs in is equally as important to authorize as the domain that flXHR.swf comes from.

As such, flXHR enforces more strictness in the policy checking phase, by enforcing that both page-domain and SWF-domain must be found to be authorized in the server policy. If not, the communication attempt fails as a 'security sandbox violation'.

This example demonstrates the dual checking of domains. The example (like all others) attempts to communicate with 'test.getify.com/flXHR-tests'. The policy on that server allows only for 'flxhr.flensed.com' authorization, meaning that both SWF-domain and page-domain must match that for flXHR to work. If you look at the source for this page, flXHR.js is linked absolutely from 'flxhr.flensed.com', so the SWF-domain will always pass. However, this page can be viewed either under 'www.flensed.com' or 'flxhr.flensed.com'. If you view the page with 'www.flensed.com', the communication will be blocked because of the server policy. If you switch to 'flxhr.flensed.com' as the page-domain, the communication will work properly as expected.