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:

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.