This article which I found from Adobe secure and they detailed about how to communicate a swf from other domain using cross domain policy. Same I am posting here by SRK.

Loading remote content

One of the most common tasks you may want to do is fetch images, sounds, or other data from a remote website. If the content is from a different domain than the requesting SWF file, then Flash Player may need to check with the remote domain to confirm whether you have permission to access that content. The following sections describe when permission is needed and how to obtain it.

Loading content from different domains

Related threats: Cross-domain privilege escalation

By default, Flash Player will follow the same-origin policy used by browsers which says that content within a single domain can access all the other content and data hosted on the same domain name. In addition, a site can present content from other domains but it can not directly access the data belonging to those other domains. For example, the same-origin policy will allow a piece of content on www.a.com to access all of the other data associated with www.a.com. The site www.a.com can also include an iframe showing the web page for www.b.com. However, the same-origin policy prohibits www.a.com from accessing www.b.com’s cookies or interacting with the JavaScript on www.b.com’s page.

Flash Player considers the full domain name used to establish content’s origin to be its security domain. For Flash Player, a SWF file’s domain is defined by where the SWF file is hosted. If a web page at the domain www.a.com includes an object tag to load a SWF from the domain www.b.com, then the SWF considers its security domain to be defined by www.b.com. Other SWF files hosted on the www.a.com site will not have full access to the SWF loaded from the www.b.com site because they are loaded from different security domains. Flash Player matches on the complete domain name and therefore the domain www.a.com is considered to be a different security domain from the domain home.a.com. Flash Player also separates content loaded from www.a.com over HTTPS and content loaded from www.a.com over HTTP into separate security domains.

Unlike the browser, Flash Player contains several methods for expanding the same-origin protections to include more than one domain name. Therefore the owner of the site www.a.com can tell Flash Player that the site’s content can be shared with the domain home.a.com. This allows website owners with multiple domain names to have interaction between their sites. Many of these methods support the use of wildcards for when developers want to share their data with the world. From a security perspective, wildcards need to be used with discretion since you are allowing everyone access to your data.

Splitting a single domain name into two security domains by using IP addresses

In addition to incorporating many domain names into one security domain, it is also possible to split one domain name into two security domains. This may be necessary if you only have one domain name available but you have SWF files with two different trust levels. To accomplish this, you can take advantage of the fact that Flash Player does not associate domain names with IP addresses.

If the site www.example.com is hosted at the IP address 1.2.3.4, then Flash Player will consider a SWF loaded by the URL http://www.example.com/my.swf to be in a different security domain then the SWF loaded by the URL http://1.2.3.4/my.swf. This approach can be useful if a site allows untrusted users to upload SWF files. Since the site owners want to protect their SWF files from being accessed by malicious SWF files uploaded by a user, the site owners could reference the trusted SWF files using the domain name in the URL and then load the potentially malicious user-submitted SWF files using an IP addresses within the URL

Implementing cross-domain files

Related threats: Cross-domain privilege escalation, insufficient authorization restrictions

If you’d like to research how to use crossdomain.xml files, see Overview of permission controls on Adobe LiveDocs and Cross-domain policy file usage recommendations for Flash Player on the Flash Player Developer Center.

Cross-domain files are one method for expanding the same-origin policy to allow multiple domain names to be considered part of the same origin. A cross-domain policy file is a way for the server hosting the file to acknowledge that its content can be considered to be part of the same origin as domains listed within the cross-domain file. Cross-domain files served from a web server on port 80 or 443 are considered to be HTTP policy files and can control policies for web requests. Cross-domain files hosted from other ports are considered to be socket policy files. Socket policy files will be discussed later.

Cross-domain files are one method for expanding the same-origin policy to allow multiple domain names to be considered part of the same origin. A cross-domain policy file is a way for the server hosting the file to acknowledge that its content can be considered to be part of the same origin as domains listed within the cross-domain file. Cross-domain files served from a web server on port 80 or 443 are considered to be HTTP policy files and can control policies for web requests. Cross-domain files hosted from other ports are considered to be socket policy files. Socket policy files will be discussed later.

The crossdomain.xml file can be used to specify three aspects of access to the HTTP server:

• What domains are trusted to be within the same origin of the server

• Whether communication between HTTP and HTTPS content is allowed for the listed domain names

• It implicitly grants socket access to ports greater than 1024 (this feature will soon be removed in future versions of Flash Player)

These cross-domain controls are available to the distributor of content and can apply to either the entire website or just one portion. Creators of SWF files also have the ability to define cross-domain controls through the use of the Security.allowDomain() method which I discuss later. The Security.allowDomain() method is a more granular way of granting cross-domain permissions on a per-file basis.

It is also important to note that Flash Player, like most browsers, does not prevent cross-domain sending of data. Flash Player only attempts to prevent cross-domain loading of data. If the website at home.a.com wants to perform an HTTP POST of data to www.a.com using a method that does not return a response to Flash Player, then it can do so without the need for a cross-domain file. If the SWF at home.a.com needs to access the response data from the request, then a cross-domain policy file is necessary.

Here are some situations that require using the crossdomain.xml file:

• When performing image extraction, such as using Bitmap.draw() or Loader.content, is required to a movie or image from another domain

• When performing sound data extraction on sound loaded from another domain such as ID3Info and computeSpectrum

• When an image is being loaded in an HTML text field from another domain
• When it is necessary to authorize sockets to connect to ports greater than 1024

• When data will be directly loaded via API calls such as LoadVars, URLLoader, or XML.load by another domain

• When a web administrator wants to explicitly block all cross-domain loading requests to their site

• When a SWF on a remote HTTP server needs to load data from within an HTTPS protected section of the server’s website

It is not necessary to use a crossdomain.xml file:

•  When an image from another domain is loaded for presentation as a child without      accessing anything inside of it

• When displaying or playing data from an RTMP server without trying to access video data or sound spectrum data

• When loading an image from the same domain as the loader

• When loading a SWF file since cross-domain permissions for SWF-to-SWF communication is controlled by Security.allowDomain()

In order to successfully load remote content into a SWF file, a remote domain has to place a crossdomain.xml file in the directory of the content or one its parent directories. In order to successfully load remote content into a SWF file, a remote domain has to place a crossdomain.xml file in the directory of the content or one its parent directories. Before making a request to a new remote domain, Flash Player will verify that the settings to allowNetworking permit access to remote domains . Next, Flash Player needs to request the crossdomain.xml file to determine whether the current domain is allowed to load the remote domain’s content. If the current domain is not listed in the crossdomain.xml file or the file does not exist, then access to the content is denied and an exception will be thrown when you attempt to access the data.

Cross-domain files can be used to explicitly deny access globally. If a cross-domain file is not present, then access is also denied. Access will also be explicitly denied to everyone by creating a crossdomain.xml file with no entries in the root directory and a site-control policy set to none:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
<-- No one can have raw access to any of the content on this site through Flash Player -->
<-- This is the only cross-domain policy file on this server -->
<site-control permitted-cross-domain-policies="none" />
</cross-domain-policy>

Using wildcards in conjunction with domain names

If the domain has multiple sub-domains that change frequently, administrators can use a wildcard in conjunction with the parent domain name by specifying domain="*.mysite.com" instead of domain= "*". Below are additional sample valid entries for a crossdomain.xml file that demonstrate alternatives to using the “*” wildcard:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">
<!-- Policy file for mysite.com -->
<cross-domain-policy>
<!-- This is the only cross-domain policy file for this server -->
<site-control permitted-cross-domain-policies="master-only"/>
<!— Administrators can set multiple entries with a wildcard on the sub-domain to avoid setting domain="*"-->
<allow-access-from domain="*.mysite.com" />
<allow-access-from domain="*.myothersite.com" />
</cross-domain-policy>