Loading assets

The most common task that developers perform that requires an understanding of security is loading external assets.

Data compared to content

The Flash Player security model makes a distinction between loading content and accessing or loading data. Content is defined as media: visual media that Flash Player can display, such as audio, video, or a SWF file that includes displayed media. Data is defined as something that you can manipulate only with ActionScript code.

You can load data in one of two ways: by extracting data from loaded media content, or by directly loading data from an external file (such as an XML file) or socket connection. You can extract data from loaded media by using the BitmapData.draw() method, the Sound.id3 property, or the SoundMixer.computeSpectrum() method. You can load data by using classes such as the SWFLoader, URLStream, URLLoader, Socket, and XMLSocket classes.

The Flash Player security model defines different rules for loading content and accessing data. Loading content has fewer restrictions than accessing data. In general, content such as SWF files, bitmaps, MP3 files, and videos can be loaded from anywhere, but if the content is from a domain other than that of the loading SWF file, it will be partitioned in a separate security sandbox.

When you load sub applications into a main application with the SWFLoader control, the sandbox into which you load it determines the level of interoperability between the applications. For more information, see About security domains.

Loading remote assets

Loading remote or network assets relies on three factors:

  • Type of asset. If the target asset is a content asset, such as an image file, you do not need any specific permissions from the target domain to load its assets into your application. If the target asset is a data asset, such as an XML file, you must have the target domain’s permission to access this asset. For more information on the types of assets, see Data compared to content.

  • Target domain. If you are loading data assets from a different web domain, the target domain must provide a crossdomain.xml policy file. This file contains a list of URLs and URL patterns that it allows access from. The calling domain must match one of the URLs or URL patterns in that list. If the target asset is a SWF file, you can also provide permissions by calling the loadPolicyFile() method and loading an alternative policy file inside that target SWF file. For more information, see Using cross-domain policy files.

  • Loading SWF file’s sandbox. To load an asset from a network address, you must ensure that your SWF file is in either the remote or local-with-networking sandbox. To ensure that a SWF file can load assets over the network, you must set the use-network compiler option to true when you compile the application. This is the default. If the application was loaded from the local file system with use-network set to false, the application is put in the local-with-filesystem sandbox and it cannot load remote SWF files.

Loading assets from a remote location that you do not control can potentially expose your users to risks. For example, the remote website B contains a SWF file that is loaded by your website A. This SWF file normally displays an advertisement. However, if website B is compromised and its SWF file is replaced with one that asks for a username and password, some users might disclose their login information. To prevent data submission, the loader has a property called allowNetworking with a default value of never.

Using cross-domain policy files

To make data available to SWF files in different domains, use a cross-domain policy file. A cross-domain policy file is an XML file that provides a way for the server to indicate that its data and documents are available to SWF files served from other domains. Any SWF file that is served from a domain that the server’s policy file specifies is permitted to access data or assets from that server.

When a Flash document attempts to access data from another domain, Flash Player attempts to load a policy file from that domain. If the domain of the Flash document that is attempting to access the data is included in the policy file, the data is automatically accessible.

The default policy file is named crossdomain.xml and resides at the root directory of the server that is serving the data. The following example policy file permits access to Flash documents that originate from foo.com, friendOfFoo.com, *.foo.com, and 105.216.0.40:

<?xml version="1.0"?> 
<!-- http://www.foo.com/crossdomain.xml --> 
<cross-domain-policy> 
    <site-control permitted-cross-domain-policies="by-content-type"/> 
    <allow-access-from domain="www.friendOfFoo.com"/> 
    <allow-access-from domain="*.foo.com"/> 
    <allow-access-from domain="105.216.0.40"/> 
</cross-domain-policy>

You can also configure ports in the crossdomain.xml file. For more information about crossdomain.xml policy files, see Flash Player security.

You can use the loadPolicyFile() method to access a nondefault policy file.

Loading local assets

In some cases, your SWF file might load assets that reside on the client’s local file system. This typically happens when the application is embedded on the client device and loaded from a network. If the application is allowed to access local assets, it cannot access network assets.

To ensure that an application can access assets in the local sandbox, the application must be in the local-with-filesystem or local-trusted sandbox. To ensure this, you set the use-network compiler option to false when you compile the application. The default value of this option is true.

When you load another SWF file that is in the local file system into your application with a class such as SWFLoader, and you want to call methods or access properties of that SWF file, you do not need to explicitly enable cross-scripting.

If the SWF files are in different sandboxes (for example, you loaded the main SWF file into the local-with-network sandbox, but loaded the asset SWF file from the network), you cannot cross-script because they are in different sandboxes. Remote SWF files cannot load local SWF files, and vice versa.