Securely deploying cross-domain policy files

1. Avoid full wildcard permissions (domain="*",  headers="*", to-ports="*").  There are only a small number of legitimate use cases for full wildcard (*) permissions.  If granting full permission is absolutely necessary, then the best practice is to create a sub-domain on your site whose explicit purpose is to serve cross-domain data.  Another option is to leverage Flash Player's support of per-directory cross-domain permissions and place the data and the full wildcard cross-domain policy within a sub-directory of the site dedicated for that purpose.  Full wildcards on internal networks can also be dangerous since they can result in external content being granted access to internal resources. A full wildcard should also never applied to the headers attribute of the allow-http-request-headers-from element or the to-ports attribute of the allow-access-from element in production.  Once a wildcard permission has been deployed, it can be very challenging to restrict permissions at a later date because there is no easy way to identify what content depends on that permission.

3. Avoid cross-domain permissions on sites that require authentication.  Any data that requires authentication for access probably should not be available to third-party domains.  Flash Player does not provide access to the header of an HTTP response.  Therefore developers may assume that SWF content cannot gain access to the session information stored within the cookie headers.  However, some architectures will add the session information as a parameter onto the end of a URL contained within the response body where an attacker can gain access to it.  Once an attacker has access to the session information of the victim, they can impersonate that user.

4. Cross-domain policies require periodic maintenance.  Your web site will grow and change over time and you will need to reevaluate the cross-domain permissions with respect those changes.  If you are granting permissions to domains outside of your control, then keep in contact with that party to ensure that the permissions are still necessary and that they are still used within the same context.  You can limit your risk by periodically removing excess permissions.

5. Cross-domain permissions are not the only method for sharing data between domains.  Rather than using the client to bridge two domains, consider using server-side code to make the cross-domain request via a server-to-server channel.  Server-side code can enforce stricter controls on the request and act as a proxy between the client and the second domain.  This has the trade-off of increasing traffic to the server but may allow for a more controlled channel.  Be sure to consider all of your options before determining the best solution.

For further information and best practice guidance, please see: