Workflow developers should have a thorough understanding of what is and isn't allowed when enhanced
security is enabled. For example, a cross-domain policy file may be needed if privileged locations are not
set. same-origin and cross-domain examples shows examples of combinations of PDF and server
locations for both same-origin and cross-domain data requests.
• Use same-origin communications exclusively if you can.
• Never use a standalone * wildcard to provide unlimited cross domain access. Keep your
permissions as granular as possible.
• Don't hard code the hostname of same-origin communications.
• Choose one full qualified domain name. Use a redirect for alternate variations.
• Use a "www" domain name when you staging and production servers and want cross domain
access to work consistently without modification during the development-deployment life cycle.
• Use SSL consistently (don't use cross domain files to help
http://example.com
and
https://example.com
communicate with each other. Use secure="false" if you have to mix and match
http and https.
• For local files and files referenced by a file URL, provide access via a certificate fingerprint.
7.2.3 Typical policy
Policy files grant read access to data, permit a client to include custom headers in cross-domain requests,
and grant permissions for socket-based connections. The most common location for a policy file on a
server is in the root directory of a target 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 hosted this way are known as master policy files. allow-access-from: Allowing access
to root domains shows a typical URL (i.e. non-socket) master policy file which allows access to the
example.com root domain with and without the www subdomain as well as any subdomains.
allow-access-from: Allowing access to root domains
<?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"
/>
<allow-access-from
domain="www.example.com"
/>
<allow-http-request-headers-from
domain="*.adobe.com"
headers="SOAPAction"
/>
</cross-domain-policy>
The
site-control
element here specifies that only this master policy file should be considered valid on
this domain. Below that, the
allow-access-from element
specifies that content from the
example.com requesting domain can access any data within the target domain (the domain in which this
policy file has been saved). Finally, the
allow-http-request-headers-from
element indicates that
a
SOAPAction
header is also allowed to be sent with requests made to the target domain from
adobe.com.
7.2.4 Permissive vs. restrictive 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 requesting domain:
cross-domain-policy: Least permissive policy
Application Security Guide
Section 7 Cross Domain Configuration
Section 7 Cross Domain Configuration
Page 57
