Once in a while, some client requested the file crossdomain.xml from my web server.
The server dutifully returned HTTP status code 404: Not Found.
Well, until today.
I've created a crossdomain.xml file, and from now own, the server will return that file.
The crossdomain.xml file is not a web standard.
The crossdomain.xml file is the Flash policy file, and it is merely an Adobe standard.
To be more precise, it started as a Macromedia standard and became an Adobe standard when Adobe bought Macromedia.
Support for the Flash policy file was introduced on 2003 Aug 1, along with Flash Player version 7. At that time, Flash was still known as Macromedia Flash, as Adobe had not bought Macromedia yet. When Macromedia created the Flash policy file, it used the macromedia.com domain for the DTD files mentioned within those files. Today, Flash policy files still use the macromedia.com domain name.
Macromedia developed the Cross-domain policy file specification in support of Flash applications. Theoretically, the Flash policy file can be used by other applications as well, but few outside the community of Flash coders are aware of it. The Flash policy file is mainly used by Flash applications, but not solely by Flash applications.
Microsoft Silverlight uses a Silverlight policy file named clientaccesspolicy.xml.
However, Silverlight does but takes advantage of the possible existence of a crossdomain.xml file.
If Silverlight cannot find the clientaccesspolicy.xml file, it looks for the crossdomain.xml,
and if the cross-domain policies in that file are sufficiently permissive, it will continue as if there is clientaccesspolicy.xml that grants the necessary permissions.
Your web site should not allow more access than necessary.
You should default to using the most restrictive policies, and only allow access as necessary.
Adobe's Cross-domain policy file specification documents the least permissive crossdomain.xml file:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<site-control permitted-cross-domain-policies="none"/>
</cross-domain-policy>
The meaning of this crossdomain.xml is very simple: no cross-domain access allowed.
That does not mean that no one is allowed to access the content of this server from anywhere else.
Remember, crossdomain.xml isn't a web standard, but merely an Adobe standard.
Normal web browser does not care about the crossdomain.xml or what it says, and everyone can continue to visit the site as before.
This most restrictive Flash policy file does not even mean that you cannot access the site using a Flash application.
It merely says that you cannot load site content using a Flash application on another domain.
It simply restricts access to site resources to Flash apps that are hosted on the site itself.
This web site does not use any Flash apps, but if I ever decided to use some Flash apps, I still would not have to change that file.
I created a crossdomain.xml for one simple reason; to reduce the server's error log.
This web site adheres to web standards.
Flash isn't a web standard, so this web site does not use Flash.
This web site does not offer resources to Flash apps running on other domains either.
This web site does not need a crossdomain.xml file at all.
I created a crossdomain.xml for one simple reason; to reduce the server's error log.
It used to be that a client would request crossdomain.xml, upon which the web server would
not only return HTTP status code 404, but also write an entry to the error log.
Now that the crossdomain.xml file exists, client requests for that file will succeed instead of fail, and the server will not write an entry to the error log anymore.
Thus, the noise level in the error log is reduced.
By the way, information about crossdomain.xml requests continues to be available in the usage log.
If your site does not use Flash either, and you'd like an crossdomain.xml file on your site for the same reason, you can simply copy the above code, and save it to a file named crossdomain.xml in your root directory.
The beauty of the minimal crossdomain.xml code shown above is that it does not even list your domain name.
You really can simply copy & paste it for use on your own site, without having to change a thing.
This works because Flash supports the same-origin policy, and only needs the Flash policy file to control cross-domain access.
However, if you were to deploy a Flash app, that crossdomain.xml file demands that it has be hosted on exactly the same domain name, not on some subdomain.
You can explicitly specify the subdomains you use one by one, but you can also allow any subdomain by specifying your domain name with a wildcard, like this:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*.domain.tld" />
</cross-domain-policy>
An emptycrossdomain.xmlfile is all you need to get rid of failedcrossdomain.xmlrequests in your web server's error log.
The first crossdomain.xml shown above may seem like the minimal crossdomain.xml file, but it is not.
First of all, the <site-control permitted-cross-domain-policies="none"/> line could be left out,
as not allowing any cross-domain access is the default anyway.
Including that line merely makes the policy explicit.
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
</cross-domain-policy>
This isn't the minimal crossdomain.xml file either.
The truly minimal crossdomain.xml file is an empty file.
Whether the crossdomain.xml file is absent or empty does not matter to Flash.
In the absence of any explicit permissions, it simply sticks to its same-origin-policy.
An empty crossdomain.xml file is all you need to get rid of failed crossdomain.xml requests in your web server's error log.
Having an empty clientaccesspolicy.xml file reduces the number of HTTP requests Silverlight makes.
Similarly, an empty clientaccesspolicy.xml file is all that Silverlight needs to know it is not allowed to load resources from your site.
Having an empty clientaccesspolicy.xml file reduces the number of HTTP requests Silverlight makes.
When there is no clientaccesspolicy.xml file, Silverlight's request for the clientaccesspolicy.xml file returns HTTP status code 404, and Silverlight will follow up by requesting the crossdomain.xml file.
When the first request returns HTTP status code 200 and the empty clientaccesspolicy.xml file,
Silverlight understands that it is not allowed to remote load anything from your site, and will not issue that second request for the crossdomain.xml file.
This server now has both a crossdomain.xml and a clientaccesspolicy.xml file, and both are empty files.
This does not extend any permission to either Flash or Silverlight apps, but it does reduce the noise level of the error log,
and the number of requests that Silverlight makes to boot.
Copyright © Tamura Jones. All Rights reserved.