A cross-domain policy is a XML document file which is use to grant permission to web client like Adobe Flash Player to access data from different domain. When a client host an application on a domain and makes a request to access content from domain other than its own, the remote domain would required to host a cross-domain policy file which would define and grant access to application from client domain.
Policy file are also used with sockets to grant permission for socket-base connections. It is advisable, to host policy file for both same domain connection as well as connections made across domains.
Normally policy file are host on root directory of a server with file name crossdomain.xml, this is the default location. The following is the example of a typical policy file.
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="none"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"
</cross-domain-policy> |
The parent tag for any crossdomain.xml is <cross-domain-policy>tag.
<cross-domain-policy> tag has following elements
- <site-control>: <cross-domain-policy> tag can have only one site-control element. This element defines the meta-policy for the current domain. In cases where client needs to have multiple policy file on the domain, master policy file [policy file residing on root directory of the domain] decide the acceptability of the policy files on the domain. This element is of importance only if policy file is master policy file else this element is ignored. If a flash application is instructed to use a policy file in a location other than that of the master policy file, the client must first check meta-policy of the master policy file to determine if the original policy file is allowed. permitted-cross-domain-policies attribute of this elements meta-policies, it can hold following values
- none: No policy files are allowed anywhere on the server other then this file.
- master-only: Only this master policy file is allowed on the server.
- by-content-type: All policy files whose Content-Type is text/x-cross-domain-policy are only allowed. This meta-policy is only available for HTTP and HTTPS servers.
- by-ftp-filename: Only policy files whose file names are crossdomain.xml (i.e. with URLs ending in /crossdomain.xml) are allowed.
- none-this-response: This is a special meta-policy that can only be specified in an HTTP response header. It helps prevents this particular HTTP response from being interpreted as a policy file.
- all: All policy files on this domain are allowed.
By default ‘none’ value is assign to this attribute of the element.
- <allow-access-from-domain>: <cross-domain-policy> tag can have any number [zero or more] of allow-access-from elements. Each allow-access-from element can be used to define a domain or IP address from which a Flash application can access the local resources. The attribute domain specifies address of domain/IP address of Flash application which can access. If address specified is ‘*’ then it specifies that the local resource of the domain can be access by Flash application from any domain. In case if you want to grant access to your public resources by a specific domain(s), then that domain address need to be specified.
| <allow-access-from domain="www.mySite.com" /> |
The above example will give access to Flash application hosted on www.example.com domain to access the public resources. Also wildcard ‘*’ can be used to match domains that ends with the given suffix.
| <allow-access-from domain="*.mySite.com" /> |
IP address where Flash application is hosted can also be specified.
| <allow-access-from domain="127.0.0.1" /> |
By default a Flash application hosted on an HTTPS server can only access resources on remote HTTPS servers. So if secure attribute is set to false, then a Flash application on an HTTP server can access resources from an HTTPS server.
| <allow-access-from domain="*.mySite.com" secure="false" /> |
Policy file is also used while granting access to list/range of ports through which socket connection is allowed. Range of ports is specified through a dash (-)between two part numbers. List of ports are separated by comma (,). Wildcard character (*) can be used to allow all ports. The following is the example of socket-based policy file.
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.mySite.com" to-ports="507,516-523"/>
</cross-domain-policy> |
The above example will allow socket connections from domain mySite.com, including sub-domains, to ports 507, 516, 517, 518, 519, 520, 521, 522 and 523.
- <allow-http-request-header-from>: <cross-domain-policy> tag can have any number [zero or more] of allow-http-request-headers-from elements. The allow-http-request-headers-from element grants a client hosting content from another domain to send user-defined headers to the current domain, i.e., this tag grants permission to push data [in form of header] into current domain.
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-http-request-header-from domain="www.mySite.com" headers="X-My*"/>
</cross-domain-policy> |
This policy file allows any header beginning with the characters X-My from www.mySite.com to be sent to this domain.
Making domain resources inaccessible from other domain
If you don’t want any Flash application to access your data/resources form your server then you can create a crossdomain.xml file that does not include ant <allow-access-from> tag
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
</cross-domain-policy> |
Domain matching criteria followed by Flash Player
The following rules are used in determining if a value in the domain attribute of the <allow-access-from> or <allow-http-request-headers-from> elements matches an actual domain name:
- For named domains, top-level domain names (i.e. com in www.mySite.com), along with second-level domain names (i.e. mySite in www.mySite.com) and subdomains of a second-level domain (i.e. www in www.mySite.com) should match.
- Any domain used without a subdomain, are considered separate domains.
- Whenever a wildcard character (*) is used as a subdomain, it matches the domain without a subdomain.
- Wildcard character (*) is always used in place of subdomain or as an entire domain [All domain access], otherwise domain is invalid.
- IP addresses and named domains are considered separate domains, even if they refer to the same host.
- Cross-domain redirects are not allowed and, if used, a domain is considered invalid.
Examples:
| Domain Values |
Match |
Not Match |
| www.mySite.com |
www.mySite.com |
http://mySite.com
www.mySite.net
www.mysite.co.in |
| *.mySite.com |
www.mySite.com
http://mySite.com
http://www.mySite.com
http://myExample.mySite.com |
http://www.mySite.net
http://adobe.com
|
| 127.0.0.1 |
http://127.0.0.1 |
http//localhost
http://127.0.0 |
| www.mySite.* |
invalid domain |
|
