Course Vector

Notes: Cross-Domain Policy

Below is the structure of the cross-domain policy and all the allowed values. The majority of the content was aggregated from Adobe’s page on cross-domain policies.

A cross-domain policy file is an XML document that allows a web client to handle data across multiple domains. You will usually need one if the SWF is playing on Domain A and the files are located on Domain B. Policy files grant read access to data as well as permit a client to include custom headers in cross-domain requests. A policy file is also used when using Sockets during socket-based connections.

The most common location for a policy file on a server is in the root directory of a domain with the filename crossdomain.xml (e.g. http://example.com/crossdomain.xml)—the default location that clients check when a policy file is required. Policy files saved this way are known as master policy files. The following is an example of a typical, permissive URL (i.e. non-socket) master policy file:

Example

<?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="master-only"/>
	<allow-access-from domain="*"/>
	<allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>

Serving Policy Files

Ideally, all URL policy files should be served with Content-Type: text/x-cross-domain-policy. This is the same content type that the by-content-type value of the permitted-cross-domain-policies attribute uses to determine validity of a policy file. The following content types are also permissible:

• text/*
• application/xml
• application/xhtml+xml

Instead of relying entirely on master policy files for meta-policies, clients may also decide to check for a X-Permitted-Cross-Domain-Policies header in documents to specify a meta-policy. In addition to the values acceptable in permitted-cross-domain-policies, this header may also use a value of none-this-response to indicate that the current document should not be used as a policy file, despite other headers or its content.

Master Policy Files

Master policy files are policy files located in root of a domain with the filename crossdomain.xml (e.g. http://example.com/crossdomain.xml). When clients require a policy file, this is the default location for the policy file they should check. A domain should always host a master policy file to enforce its intended meta-policy.

If a client is instructed to load a policy file other than the master policy file, the master policy file will still need to be checked by the client to ensure that the meta-policy defined by the master policy file (via the <site-control> element) permits the use of the originally requested policy file. Without a master policy file, it is left to the client to enforce the default behavior.

Non-master policy files can only grant access to data within their own directory or within that directory’s subdirectories.

Domain Matching

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.example.com) should match
• For named domains, second-level domain names (i.e. example in www.example.com) should match
• Subdomains of a second-level domain (i.e. www in www.example.com), as well as the domain used without a subdomain, are considered separate domains
• When a wildcard character (*) is used as a subdomain, it also matches the domain without a subdomain
• If a wildcard is not used alone or in place of a subdomain, the domain is invalid
• IP addresses do not match named domains even if they refer to the same host
• Cross-domain redirects are not allowed and, if used, a domain is considered invalid

Domain matching examples

• www.example.com
  • Matches: http://www.example.com
  • Does Not Match: http://example.com
  • Does Not Match: http://www.example.net
  • Does Not Match: http://www.adobe.com
• *.example.com
  • Matches: http://example.com
  • Matches: http://www.example.com
  • Matches: http://subdomain.example.com
  • Does Not Match: http://www.example.net
  • Does Not Match: http://www.adobe.com
• 127.0.0.1
  • Matches: http://127.0.0.1
  • Does Not Match: http://localhost
  • Does Not Match: http://127.0.0
  • Does Not Match: http://127.0.0.2
• www.example.*
  • No matches, invalid domain

Specification

Schemas

There are a number of different schemas you can use with your cross-domain policy file. Anything but the default is usually used on a case by case basis.

• Generic DTD (Default) – http://www.adobe.com/xml/dtds/cross-domain-policy.dtd
• Generic XSD – http://www.adobe.com/xml/schemas/PolicyFile.xsd
• HTTP XSD – http://www.adobe.com/xml/schemas/PolicyFileHttp.xsd
• HTTPS XSD – http://www.adobe.com/xml/schemas/PolicyFileHttps.xsd
• FTP XSD – http://www.adobe.com/xml/schemas/PolicyFileFtp.xsd
• Socket XSD – http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd

cross-domain-policy tag

The <cross-domain-policy> element is the root element for cross-domain policy files. It acts as a container for policy file definitions and has no attributes of its own to define cross-domain policies.

The following is the least permissive master policy file definition. It enforces a meta-policy that restricts any policy file, including this one, from granting permissions of any type to any domain:

<?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"/>
</cross-domain-policy>

The following is the most permissive master policy file definition (strongly not recommended). It allows any policy file defined on the server of this domain to grant permissions, allows access to any file on the server, and permits any header to be sent to the server—all of this possible even through HTTPS despite the source being HTTP:

<?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="all"/>
	<allow-access-from domain="*" secure="false"/>
	<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>

The following policy file is an example of a socket-based policy that would be served to a client through a socket connection. It allows socket connections from the domain example.com, including subdomains, to ports 1100, 1200, and 1212:

<?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="*.example.com" to-ports="1100,1200,1212"/>
</cross-domain-policy>

site-control tag – [Master policy file only]

The <site-control> element defines the meta-policy for the current domain. A meta-policy decides what policy files on a domain are acceptable in the case that a client needs to use a policy file other than the domain’s master policy file—the policy file located in the domain’s root under the name crossdomain.xml. The <site-control> element is specific to master policy files; if used within a policy file that is not the master policy file, the <site-control> element will be ignored.

• permitted-cross-domain-policies : Specifies the meta-policy. This should contain any one of the following values:
  • none: No policy files are allowed at all, anywhere on the server, including this master policy file
  • master-only: Only this master policy file is allowed
  • by-content-type: [HTTP/HTTPS only] Only policy files served with Content-Type: text/x-cross-domain-policy are allowed
  • by-ftp-filename: [FTP only] Only policy files whose filenames are crossdomain.xml (i.e. URLs ending in /crossdomain.xml) are allowed
  • all: All policy files on this domain are allowed

The default value is master-only for all policy files except socket policy files, where the default is all.

Though the following policy file does not allow data access for this domain, it defined a meta-policy that allows other policy files within this domain to determine how access will be handled. A client will need to load a policy file other than the master for permissions related to this domain:

<?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="all"/>
</cross-domain-policy>

The following defines a meta-policy that allows only this master policy file to function for this domain. It allows access to data on example.com and all of its subdomains:

<?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="master-only"/>
	<allow-access-from domain="*.example.com"/>
</cross-domain-policy>

allow-access-from tag

The <allow-access-from> element grants another domain access to read data from the current domain. For each individual domain that is given permission, a new <allow-access-from> element is required, although multiple domains can be given access with one <allow-access-from> element by using a wildcard (*).

• domain: Specifies a domain to be granted access. Both named domains and IP addresses are acceptable values. Subdomains are considered different domains. A wildcard (*) can be used to match all domains when used alone, or multiple domains (subdomains) when used as a prefix for an explicit, second-level domain name separated with a dot (.). Specific, individual domains require separate allow-access-from elements. For more information, refer to Appendix A: Domain matching.
• to-ports: [Sockets only] A comma-separated list of ports or range of ports that a socket connection is allowed to connect to. A range of ports is specified through a dash (-) between two port numbers. Ranges can be used with individual ports when separated with a comma. A single wildcard (*) can be used to allow all ports.
• secure: [HTTPS and Sockets only, optional] When false, allows an HTTPS policy file to grant access to a request coming from an HTTP source. The default for URL policy files is true, providing only HTTPS sources permission. Using false is not recommended. Socket policy files use a default of false.

Note: An allow-access-from element in a non-master policy file can only grant another domain access to data within its own directory and subdirectories, not a directory in a higher level of that domain.

The following policy file demonstrates the most permissive use of allow-access-from granting any other domain access to the files on this domain, even if an HTTP source is accessing data on this domain through HTTPS:

<?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="*" secure="false"/>
</cross-domain-policy>

Here the policy file allows access to example.com in both uses of the root domain, with and without the www subdomain:

<?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="example.com"/>
	<allow-access-from domain="www.example.com"/>
</cross-domain-policy>

The following is a socket policy file example. This XML should be served to a client through a socket connection when requested with policy-file-request. It permits access to content from example.com or any of its subdomains through ports 507 and any port between 516 and 523, inclusive:

<?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="*.example.com" to-ports="507,516-523"/>
</cross-domain-policy>

allow-http-request-headers-from tag

The <allow-http-request-headers-from> element grants a client hosting content from another domain to send user-defined headers to the current domain (see Figure 4). Whereas the <allow-access-from> element grants permission to pull data from the current domain, this tag grants permission to push data—data in the form of headers.

• domain: Specifies a domain to be granted access. Both named domains and IP addresses are acceptable values. Subdomains are considered different domains. A wildcard (*) can be used to match all domains when used alone, or multiple domains (subdomains) when used as a prefix for an explicit, second-level domain name separated with a dot (.). Specific, individual domains require separate <allow-access-from> elements. For more information, refer to Appendix A: Domain matching.
• headers: A comma-separated list of headers that the allowed domain is permitted to send. A wildcard character (*) can be used to allow all headers or for header suffixes, allowing for headers that start with the same characters but end with different characters.
• secure: (HTTPS only, optional) When false, allows an HTTPS policy file to grant access to a request coming from an HTTP source. The default is true, providing only HTTPS sources permission. Using false is not recommended.

Note: An allow-http-request-headers-from element in a non-master policy file can only allow headers to be sent to pages within the directory in which the policy file is defined and that directory’s subdirectories.

Here, any domain is allowed to send the SOAPAction header to this 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-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>

The following policy file allows the Authorization header and any header beginning with the characters X-Foo from www.example.com to be sent to this domain. If a request is coming from foo.example.com, only headers beginning with the characters X-Foo are allowed, not Authorization:

<?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-headers-from domain="www.example.com" headers="Authorization,X-Foo*"/>
	<allow-http-request-headers-from domain="foo.example.com" headers="X-Foo*"/>
</cross-domain-policy>

policy-file-request tag

The policy-file-request element is not specific to policy file documents. Rather, policy-file-request is the root element of a single-node XML document used by a client to request policy file information from a socket server. Upon reception of this document, a socket server should provide the client with the necessary policy file so that the client can continue with the connection or close it if the policy file does not permit it:

<policy-file-request/>

Policy files for sockets should always be socket-based. URL policy files from an HTTP source should not be used to provide permissions to socket connections.

Note: Adobe Flash Player allowed HTTP policy files to work for socket connections prior to version 9,0,124,0.

Flash Version Support

Adobe Flash Player has supported the use of cross-domain policy files since Flash Player 6. Certain policy file features weren’t implemented until later versions of the player.

• Future
  • <site-control>’s permitted-cross-domain-policies default for non-socket policy files is master-only
• 9,0,124,0 (8,0,42,0)
  • <allow-http-request-headers-from> element
• 9,0,115,0
  • <site-control> element (permitted-cross-domain-policies default is “all“)
• 7,0,19,0
  • Socket-based policy files
  • Use of policy-file-request
• 7,0,14,0
  • Exact domain matching where subdomains are considered separate domains
  • <allow-access-from>’s secure attribute and a separation of HTTPS from HTTP
• 6,0,21,0
  • Basic cross-domain policy file support with <allow-access-from> element (domain and to-ports attributes)
  • Policy files for sockets were hosted through HTTP only (URL policy files)

Leave a comment

3 Comments to Notes: Cross-Domain Policy