What is Security
In Macromedia Flash Basic 8 and
Macromedia Flash Professional 8, you can use ActionScript to load data from
external sources into a SWF file or send data to a server. When you load data
into a SWF file, you need to understand and accommodate the Flash 8 security
model. When you open a SWF file on your hard disk, you might need to make
special configurations so you can test your file locally.
About compatibility with previous Flash Player
As a result of the
security feature changes in Flash Player 7, content that runs as
expected in Flash Player 6 or earlier might not run as expected in
later versions of Flash Player. For example, in Flash Player 6, a
SWF file that resides in www.macromedia.com could read data on a
server located at data.macromedia.com; that is, Flash Player 6
allowed a SWF file from one domain to load data from a similar
In Flash Player 7 and
later, if a version 6 (or earlier) SWF file attempts to load data
from a server that resides in another domain, and that server
doesn't provide a policy file that allows reading from that SWF
file's domain, the Macromedia Flash Player Settings dialog box
appears. The dialog box asks the user to allow or deny the
cross-domain data access.
If the user clicks
Allow, the SWF file can access the requested data; if the user
clicks Deny, the SWF file cannot access the requested data.
To prevent this dialog box from appearing, you should create a
security policy file on the server providing the data. For more
information, see Allowing cross-domain data loading.
Flash Player 7 and later do not allow cross-domain access without
a security policy file.
Flash Player 8 changed the way it handles
System.security.allowDomain. A Flash 8 SWF file that calls
System.security.allowDomain with any argument, or any other SWF
file that uses the wildcard (*) value, permits access only to
itself. There is now support for a wildcard (*) value, for
example: System.security.allowDomain("*") and
System.security.allowInsecureDomain("*"). If a SWF file of version
7 or earlier calls System.security.allowDomain or
System.security.allowInsecureDomain with an argument other than
wildcard (*), this will affect all SWF files of version 7 or lower
in the calling SWF file's domain, as it did in Flash Player 7.
However, this kind of call does not affect any Flash Player 8 (or
SWF files in
the calling SWF file's domain. This helps minimize legacy content
breaking in Flash Player.
Flash Player 8 does not allow local SWF files to communicate with
the Internet without a specific configuration on your computer.
Suppose you have legacy content that was published before these
restrictions were in effect. If that content tries to communicate
with the network or local file system, or both, Flash Player 8
stops the operation, and you must explicitly provide permission
for the application to work properly. For more information, see
About local file security and Flash Player
Flash Player 8 has made
enhancements to the security model, in which Flash applications and
SWF files on a local computer are not allowed to communicate with
both the Internet and the local file system by default. A local SWF
file is a SWF file that is locally installed on a user's computer,
not served from a website, and does not include projector (EXE)
NOTE : The
restrictions that are discussed in this section do not affect SWF
files that are on the Internet.
When you create a FLA
file, you can indicate whether a SWF file is allowed to communicate
with a network or with a local file system. In previous versions of
Flash Player, local SWF files could interact with other SWF files
and load data from any remote or local location. In Flash Player 8,
a SWF file cannot make connections to the local file system and the
Internet. This is a safety change, so a SWF file cannot read files
on your hard disk and then send the contents of those files across
restriction affects all locally deployed content, whether it is
legacy content (a FLA file created in an earlier version of Flash)
or created in Flash 8. Suppose you deploy a Flash application, using
Flash MX 2004 or earlier, that runs locally and also accesses the
Internet. In Flash Player 8, this application now prompts the user
for permission to communicate with the Internet.
When you test a file on
your hard disk, there are a series of steps to determine whether the
file is a local trusted document or a potentially untrusted
document. If you create the file in the Flash authoring environment
(for example, when you select Control > Test Movie), your file is
trusted because it is in a test environment.
In Flash Player 7 and
earlier, local SWF files had permissions to read from both a local
file system and the network (such as the Internet). In Flash Player
8, local SWF files can have the following levels of permission:
Access the local file
system only (default) A local SWF file can read from the local file
system and universal naming convention (UNC) network paths but
cannot communicate with the Internet. For more information on local
file access SWF files, see Access local files only (default).
Access the network only
A local SWF file can access the network (such as the Internet) but
not the local file system where it is installed. For more
information on network-only SWF files, see Access network only.
Access to the local
file system and the network A local SWF file can read from the local
file system where it is installed, read and write to and from
servers, and can cross-script other SWF files on either the network
or the local file system. These files are trusted, and behave like
they did in Flash Player 7. For more information on local and
network access SWF files, see Access file system and network.
Understanding local security sandboxes
There are several different
security sandboxes in the Flash Player. Each one determines how a SWF file can
interact with the local file system, the network, or both the local file system
and network at the same time. Restricting how a file can interact with the local
file system, or the network helps keep your computer and files safe.
Understanding security sandboxes helps you develop and test Flash applications
on your computer without encountering unexpected errors.
For security purposes, Flash Player
8 places all local SWF files, including all legacy local SWF files, in the
local-with-file-system sandbox, by default (unless some other setting is made).
For some legacy (earlier than Flash Player 8) SWF files, operations could be
affected by enforcing restrictions on their access (no outside network access),
but this provides the most secure default for the users' protection.
From this sandbox, SWF files may
read from files on local file systems or UNC network paths (by using the
XML.load() method, for example), but they may not communicate with the network
in any way. This assures the user that local data cannot be leaked out to the
network or otherwise inappropriately shared.
When local SWF files are assigned
to the local-with-networking sandbox, they forfeit their local file system
access. In return, the SWF files are allowed to access the network. However, a
local-with-networking SWF file still is not allowed to read any network-derived
data unless permissions are present for that action. Therefore, a
local-with-networking SWF file has no local access, yet it has the ability to
transmit data over the network and can read network data from those sites that
designate site-specific access permissions.
SWF files assigned to the
local-trusted sandbox can interact with any other SWF files, and load data from
anywhere (remote or local).
About Flash Player security settings
Macromedia has designed
Flash Player to provide security settings that do not require you to
explicitly allow or deny access in most situations. You might
occasionally encounter legacy Flash content that was created using
older security rules for Flash Player 7 or earlier. In these cases,
Flash Player lets you allow the content to work as the developer
intended, using the older security rules; or, you can choose to
enforce the newer, stricter rules. The latter choice ensures that
you only view or play content that meets the most recent standards
of security, but it may sometimes prevent older Flash content from
All users who view SWF
files (including non-Flash developers) can set permissions globally
through the Global Security Settings panel in Flash Player's
Settings Manager (shown in the following figure).
When older content runs
in a newer version of the player, and Flash Player needs you to make
a decision about enforcing newer rules or not, you may see one of
the following pop-up dialog boxes. These dialog boxes ask your
permission before allowing the older Flash content to communicate
with other locations on the Internet:
A dialog box might
appear alerting you that the Flash content you are using is trying
to use older security rules to access information from a site
outside its own domain, and that information might be shared between
two sites. Flash Player asks if you want to allow or deny such
In addition to
responding to the dialog box, you can use the Global Security
Settings panel to specify whether Flash Player should always ask for
your permission, through the dialog box, before allowing access;
always deny access, without asking first; or always allow access to
other sites or domains without asking your permission.
(Flash Player 8 only) A
dialog box might appear alerting you that a SWF file is trying to
communicate with the Internet. Flash Player 8 doesn't let local
Flash content communicate with the Internet, by default.
Click Settings to access the Global Security Settings panel, where
you can specify that certain Flash applications on your computer may
communicate with the Internet.
To change your security
settings or learn more about your options, you use the Global
Security Settings panel. Use this panel to reset the privacy
settings in Macromedia Flash Player:
If you select Always
Deny and then confirm your selection, any website that tries to use
your camera or microphone is denied access. You are not asked again
whether a website can use your camera or microphone. This action
applies both to websites you have already visited and to those you
haven't yet visited.
If you select Always
Ask and then confirm your selection, any website that tries to use
your camera or microphone must ask your permission. This action
applies both to websites you have already visited and to those you
haven't yet visited.
If you previously
selected Remember in the Privacy Settings panel (see the following
figure) to permanently allow or deny access for one or more
websites, selecting Always Ask or Always Deny has the effect of
deselecting Remember for all those websites. In other words, the
selection you make here overrides any previous selections you may
have made in the Privacy Settings panel, shown in the following
After you select either Always Ask or Always Deny (or instead of
doing so), you can specify privacy settings for individual websites
that you have already visited. For example, you might select Always
Deny here, then use the Website Privacy Settings panel and select
Always Allow for individual websites that you know and trust.
For locally deployed
content and local data, users have another option: They can specify
which SWF files may access the Internet using the Global Security
Settings panel. For more information on specifying settings in the
Global Security Settings panel, see Specifying trusted files using
the Settings Manager. For more information on the Global Security
Settings panel, see
NOTE : The
selections users make in the Global Security Settings panel override
any decisions made in the security pop-up dialog box.
About local file security and projector files
Projector files and the
SWF files contained within them or loaded into the projector at
runtime are not affected by local file security restrictions,
because the end user must run the executable to use the SWF file.
There are no changes to security and projector files in Flash Player
8; it has the same level of access and security as earlier versions
of Flash Player.
Remember that users are
often cautious about executing projector files. A projector file is
an executable EXE or Macintosh application, and users should be
careful about running such files on their computers. If you
distribute an application using projector files, some users might
not install it.
In addition, a
projector file embeds a specific version of Flash Player inside the
projector, which might be older than the latest version of Flash
Player available for download from the Macromedia website. The Flash
Player that's embedded within the projector file might be a legacy
version if the projector was created with an older version of Flash,
or an edition of Flash Player was released after the current version
of the Flash authoring tool. For these reasons, you should
distribute applications using SWF files when possible.
About troubleshooting legacy SWF files
Some legacy FLA and SWF
files (created with Flash MX 2004 and earlier) might not work when
you test or deploy them locally (on a hard disk) because of security
changes in Flash 8. This might happen when a SWF file tries to
access websites outside its domain, and, in this case, you need to
implement a cross-domain policy file.
You might have FLA or
SWF files created in Flash MX 2004 or earlier that have been
distributed to users who do not use the Flash 8 authoring tool but
have upgraded to Flash Player 8. If your locally tested or deployed
legacy content (an old SWF file on a user's hard disk) breaks
because it tries to communicate with the Internet when playing in
Flash Player 8, you must rely on users to explicitly trust your
content in order for it to play properly (by clicking a button in a
To learn how to fix
legacy content for playback on a local computer, see Fixing legacy
content deployed on local computers.
Fixing legacy content deployed on local computers
If you published SWF
files for Flash Player 7 or earlier that are deployed on local
computers and communicate with the Internet, users must explicitly
allow Internet communication. Users can stop content from breaking
by adding the location of the SWF file on their local computer to
the trusted sandbox in the Settings Manager.
To fix SWF files for
local playback, use any of the following options:
Redeploy Run the Local
Content Updater. The Local Content Updater reconfigures your SWF
file to make it compatible with the Flash Player 8 security model.
You reconfigure the local SWF file so it can either access only the
network or only the local file system. For more information, and to
download the Local Content Updater,
Republish and redeploy
Republish the file with Flash Basic 8 or Flash Professional 8. The
authoring tool requires you to specify in the Publish Settings
dialog box whether a local SWF file can access the network or the
local file system--but not both. If you specify that a local SWF
file can access the network, you also must enable permissions for
that SWF file (and all local SWF files) in the SWF, HTML, data,
and/or server files that it accesses. For more information, see
Publishing files for local deployment.
Deploy new content Use
a configuration (.cfg) file in the #Security/FlashPlayerTrust
folder. You can use this file to set network and local access
permissions. For more information, see Creating configuration files
for Flash development.
NOTE : Any of
these options require that you either republish or redeploy your SWF
You might send your Flash 8 FLA or SWF files to a user to test or
approve and need the application to access the Internet. If your
document plays back on a local system but accesses files on the
Internet (for example, loading XML or sending variables), your user
might need a configuration file for the content to function
properly, or you might need to set up the FLA file so the
that you publish can access the network. Alternatively, you can set
up a configuration file inside the FlashPlayerTrust directory. For
more information on setting up configuration files, see Creating
configuration files for Flash development.
Use Flash Basic 8 or Flash Professional 8 to create content for
local deployment that works with Flash Player 8 local file security.
In Flash 8 publish settings, you must specify whether local content
can access the network or access the local file system, but not
You can set permission levels for a FLA file in the Publish
Settings dialog box. These permission levels affect the local
playback of the FLA file, when it plays locally on a hard disk.
NOTE : If you specify network access for a local file, you
must also enable permissions in the SWF, HTML, data, and server
files that are accessed by the local SWF file.
Network SWF files SWF files that download from a network (such
as an online server) are placed in a separate sandbox that
corresponds to their unique website origin domains. Local SWF files
that specify they have network access are placed in the
local-with-networking sandbox. By default, these files can read data
from only the same site from which they originated. Exact-domain
matching applies to these files. Network SWF files can access data
from other domains if they have the proper permissions. For more
information on network SWF files, see Access network only.
Local SWF files SWF files that operate with local file systems
or UNC network paths are placed into one of three sandboxes in Flash
Player 8. By default, local SWF files are placed in the
local-with-file-system sandbox. Local SWF files that are registered
as trusted (using a configuration file) are placed in the
local-trusted sandbox. For information on the three sandboxes, see
Access local files only (default).
For more information on the security sandbox, see Understanding
local security sandboxes.
The first two permission levels are set in the Flash authoring
environment, and the third is set using the Global Security Settings
panel or the FlashAuthor.cfg file. The following example shows what
options are available when you publish a file for testing on your
local hard disk.
To publish a document with a specified permission level:
- Open the FLA file for which you want to specify a permission
- Select File > Publish Settings > Flash.
- Find the Local Playback Security dialog box, and select one of
the following options from the pop-up menu:
- Access local files only (See Access local files only
- Access network only (See Access network only)
- Click OK to continue authoring the FLA file, or click Publish
to create the SWF file.
Access local files only (default)
To set this permission level, select Publish Settings > Flash,
and then select Access Local Files Only from the Local Playback
Security pop-up menu. This permission level lets a local SWF file
access only the local file system where the SWF file is running. The
SWF file can read from known files on the local disk without any
restrictions. However, the following restrictions apply to the
application accessing the network:
- The SWF file cannot access the network in any way. The SWF
file cannot cross-script network SWF files, or be cross-scripted
by network SWF files.
- The SWF file cannot communicate with local SWF files that have
permission to access the network only, and the SWF file cannot
communicate with HTML pages. However, in some cases communication
is allowed, such as if the HTML is trusted and allowScriptAccess
is set to always or if allowScriptAccess is not set and the SWF
file is Flash Player 7 or earlier.
Access network only
To set this permission level, select Publish Settings > Flash,
and then select Access Network Only from the Local Playback Security
pop-up menu. Local SWF files with network access can read from a
server if the server contains a cross-domain policy file with
<allow-access-from-domain= "*">. Local SWF files with network access
may cross-script other SWF files if the other SWF files, which are
being accessed, contain System.security.allowDomain("*"). A local
SWF file with network access can be cross-scripted by network SWF
files if the local SWF file contains allowDomain("*"). The SWF file
can never read from local files. In some cases, the type of SWF file
affects the access. For information, see allowDomain (security.allowDomain
method) in the ActionScript 2.0 Language Reference.
The wildcard (*) value indicates that all domains, including
local hosts, are allowed access. Be certain you want to provide this
broad level of access before using the wildcard argument.
Without any of these permissions, local SWF files with network
access can communicate only with other local SWF files that have
network access, and they can send data to servers (using XML.send(),
for example). In some cases, access is allowed if the HTML file is
Access file system and network
This level is the highest level of permission. A local SWF file
that has these permissions is a trusted local SWF file. Trusted
local SWF files can read from other local SWF files, interact with
any server, and write ActionScript for other SWF files or HTML files
that have not explicitly forbidden the file permission (for example,
with allowScriptAccess="none"). This level of permission can be
granted by the user or Flash developer in the following ways:
- Using the Global Security Settings panel in the Settings
- Using a global configuration file.
A configuration file can be installed with the SWF file, created
by a Flash developer, or added by an administrator (for all users or
the current user) or any Flash developer (for the current user).
As a Flash developer,
you frequently test Flash applications locally, so you might see a
dialog box prompt when a local Flash application tries to
communicate with the Internet. You might see this dialog box when
you test a SWF file in Flash Player if the SWF file does not have
network access. For more information on publishing SWF files with
specified permission levels, see Publishing files for local
deployment. Publishing a SWF file with one of these options means
you can communicate with the network or the local file system.
At times, you might
need to communicate with the local file system and the network when
you are testing a document. Because the new security model might
interrupt your workflow when you are authoring Flash applications,
you can use the Global Security Settings panel in Flash Player's
Settings Manager to specify which Flash applications on your
computer can always communicate with both the Internet and the local
file system. Or, you can modify the configuration file to specify
trusted directories on your hard disk.
You can specify what
Flash content on your computer may always use the older security
rules by adding the location of the content to the Global Security
Settings panel in the Flash Player Settings Manager. After you add a
location on your computer to the Security panel, content in that
location is trusted. Flash Player won't ask you for permission and
is always allowed to use the older security rules, even if Always
Deny is selected in the Security panel. The Always Trust Files in
These Locations list overrides the options in the Settings panel.
That is, if you select to always deny local and web content the
right to use the older security rules, the local files in your
trusted list are always allowed to use the older rules.
The Always trust files
list at the bottom of the panel applies specifically to Flash
content that you have downloaded to your computer, not content that
you use while visiting a website.
The following example
shows how to specify that a local SWF file can communicate with the
Internet. When you test a file in a browser locally (File > Publish
Preview > HTML), a security dialog box might appear. If you click
Settings, the Settings Manager Global Security Settings panel
To specify that a
local SWF file can communicate with the Internet and local file
In the Global Security
Settings panel, click the pop-up menu and select Add Location.
The Add Location box
If you arrived at the
Settings Manager by clicking the Settings button in a dialog box,
the Add Location box contains a path that is similar to C:\directoryname\filename.swf
or /Users/directoryname/filename.swf; this path tells you which file
tried to communicate with the Internet and was stopped by Flash
Player security. If the path contains the content that you want to
let communicate with the Internet, copy and paste the path into the
Trust This Location box. Or, click one of the Browse buttons and
find the content yourself.
You can add an
individual file or an entire directory. If you add an entire
directory, all the files and subdirectories in that directory are
trusted. Some Flash content consists of multiple related files, and
you might need to trust the entire directory where all the related
files are located. In general, avoid trusting top-level directories.
The location is added
to the Security Settings panel. Locations listed are always allowed
to use the older security rules, even if the Always Deny or Always
Ask options at the top of the Security panel are selected.
After you add trusted
locations, you must restart the local Flash content by either
refreshing the browser or restarting the player.
If you click Always
Allow, it only applies that setting to always allow legacy content
(Flash Player 7 and earlier). The setting does not "always allow"
Flash Player 8 content. It is recommended that you specify the Flash
applications and directories on your computer that can communicate
with both the Internet and the local file system.
Creating configuration files for Flash development
The Flash 8 authoring
tool sets a flag on your hard disk to identify you as a developer to
direct you to a specific developer-oriented version of the Global
Security Settings panel instead of a user-oriented Global Security
Settings panel. The flag is in the FlashAuthor.cfg file on your hard
disk, which installs automatically when the Flash Basic 8 and Flash
Professional 8 authoring tool installs.
file is located in the following approximate directories:
disk\Documents and Settings\<UserName>\Application
By default, this file
is set to LocalSecurityPrompt=Author, which means the warnings you
see on your computer treat you as a Flash developer as opposed to a
user without the authoring tool installed.
You can test your local
applications as an end user and see the warning dialog boxes that an
end user would encounter. To do so, open FlashAuthor.cfg in a text
editor, and change the LocalSecurityPrompt in the FlashAuthor.cfg
file to match the following:
You might want to provide a FlashAuthor.cfg file, with
LocalSecurityPrompt set to Author, to other developers in your
design or development process or to users who test Flash
applications on their local hard disk and do not have the Flash 8
authoring tool installed. This helps you mimic the end user's
experience with your locally deployed content.
NOTE : If the
FlashAuthor.cfg file is deleted, the file is recreated when you
launch the Flash 8 authoring tool.
In the #Security
directory on your hard disk, you can create a FlashPlayerTrust
directory where you can store unique configuration files. Inside
these files, you can specify directories or applications to trust on
your hard disk. This directory does not require administrative
access, so users without administrative permissions can set
permissions for SWF files and test applications.
If you do not specify a
directory, your content might not function as intended.
Configuration files inside a FlashPlayerTrust directory contain
directory paths. The file can contain a list of several directories,
and you can append new paths to the file. Flash Player expects one
path per line in configuration files. Any line that begins with a #
punctuator (with no leading space before it) is treated as a
To create a
configuration file to trust a directory:
Locate the #Security
folder on your hard disk.
Create a folder called
FlashPlayerTrust inside the #Security folder.
Create a new file in
the FlashPlayerTrust directory using a text editor, and save it as
You can use any unique
name for your configuration file.
Locate the directory
where you test Flash applications.
Type or paste each
directory path (any directory path on your hard disk) on a new line
in the file. You can paste multiple directory paths on separate
lines. When you finish, your file looks similar to the following
Save your changes to
Test a document that
accesses local and network files from the directory you added to the
saved in this directory can now access local files and the network.
There can be numerous
directory paths saved in each configuration file, and numerous *.cfg
files saved in the FlashPlayerTrust directory.
If you create
applications that install on an end user's hard disk, you might need
to create a configuration file in FlashPlayerTrust to specify a
trusted directory for your application. You can create configuration
files inside the FlashPlayerTrust directory that specify the
location of the trusted application. See the pervious procedure for
information on this directory and creating configuration files.
NOTE : An
installer is run by a user with administrative permission on a
You should develop a
unique naming scheme to avoid conflicts with other applications that
might install files in this directory. For example, you might want
to use your unique company and software name in the filename to
TIP : If you do
not want to use configuration files, you could publish your Flash
applications to a separate, testing server instead of providing
clients or other developers SWF files to run on their local hard
About the sandboxType property
Flash Player 8's
System.security.sandboxType property returns the type of security
sandbox in which the calling SWF file is operating.
property has one of the four following values:
remote The SWF file is
hosted on the Internet and operates under domain-based sandbox
localTrusted The SWF
file is a local file that has been trusted by the user, using either
the Global Security Settings Manager or a FlashPlayerTrust
configuration file. The SWF file can both read from local data
sources and communicate with the network (such as the Internet).
localWithFile The SWF
file is a local file that has not been trusted by the user, and was
not published with a networking designation. The SWF file can read
from local data sources but cannot communicate with the network
(such as the Internet).
SWF file is a local file that has not been trusted by the user, and
was published with Access Network Only selected in the Publish
Settings dialog box (Flash tab). The SWF file can communicate with
the network but cannot read from local data sources.
You can check the
sandboxType property from any SWF file, although a value is returned
only in files published for Flash Player 8. This means that when you
publish for Flash Player 7 or earlier, you do not know whether the
sandboxType property is supported at runtime. If the property isn't
supported at runtime, the value is undefined, which occurs when the
Flash Player version (indicated by the System.capabilities.version
property) is less than 8. If the value is undefined, you can
determine the sandbox type according to whether your SWF file's URL
is a local file or not. If the SWF file is a local file, Flash
Player classifies your SWF as localTrusted (which is how all local
content was treated prior to Flash Player 8); otherwise Flash Player
classifies the SWF file as remote.
About local-with-file-system restrictions
local-with-file-system file has not been registered using the
configuration file inside the FlashPlayerTrust directory, the Global
Security Settings panel in the Settings Manager, or has not been
granted network permission in the Publish Settings dialog box in the
Flash authoring environment.
NOTE : For
information on security sandboxes, see Understanding local security
These files include
legacy content that plays in Flash Player 8. If you are developing
content in Flash 8, or you have content that falls into one of the
following categories, you (or your users) should register the file
as trusted. For information on registering a file as trusted, see
Specifying trusted files using the Settings Manager. For information
on granting permission for local fileplayback using configuration
files, see Creating configuration files for Flash development.
SWF files have the following restrictions:
Loading other SWF files
from the network (except using non-Internet UNC paths)
Sending HTTP requests
using XMLSocket, Flash Remoting, or NetConnection
Calling getURL(/adobe-flash-help-tutorials/) except _ if you use getURL("file:...") or getURL("mailto:...")
Can interact with other
local-with-file-system files, but includes restrictions to the
as ActionScript access to objects in other SWF files).
as sender or listener and regardless of LocalConnection.allowDomain
Local-with-file-system SWF files can interact with other
local-with-file-system, non-network SWF files. However, they cannot
interact with local-with-network SWF files.
SWF files have read access to known files on the local file system.
For example, you can use XML.load() in a local-with-file-system SWF
file as long as you load from the local file system and not the
SWF files cannot communicate with HTML pages, which includes the
Inbound scripting (such
as ExternalInterface API, ActiveX, LiveConnect, and XPConnect)
By default, Flash
Player 7 and later versions prevent a SWF file served from one
domain from reading data, objects, or variables from SWF files that
are served from different domains. In addition, content that is
loaded through nonsecure (non-HTTPS) protocols cannot read content
loaded through a secure (HTTPS) protocol, even when both are in
exactly the same domain. For example, a SWF file located at http://www.macromedia.com/main.swf
cannot load data from https://www.macromedia.com/data.txt without
explicit permission; neither can a SWF file served from one domain
load data (using loadVars(), for example) from another domain.
Identical numeric IP
addresses are compatible. However, a domain name is not compatible
with an IP address, even if the domain name resolves to the same IP
The following table
shows examples of compatible domains:
The following table
shows examples of incompatible domains:
www.macromedia.com (even if this domain resolves to 22.214.171.124)
126.96.36.199 (even if www.macromedia.com resolves to this IP address)
Flash Player 8 does not
allow local SWF files to communicate with the Internet without a
proper configuration. For information on setting up a configuration
file to test content locally, see Creating configuration files for
Domain name rules for settings and local data
In Flash Player 6,
superdomain matching rules are used by default when accessing local
settings (such as camera or microphone access permissions) or
locally persistent data (shared objects). That is, the settings and
data for SWF files hosted at here.xyz.com, there.xyz.com, and
xyz.com are shared and are all stored at xyz.com.
In Flash Player 7,
exact-domain matching rules are used by default. That is, the
settings and data for a file hosted at here.xyz.com are stored at
here.xyz.com, the settings and data for a file hosted at
there.xyz.com are stored at there.xyz.com, and so on.
System.exactSettings lets you specify which rules to use. This
property is supported for files published for Flash Player 6 or
later. For files published for Flash Player 6, the default value is
false, which means superdomain matching rules are used. For files
published for Flash Player 7 or 8, the default value is true, which
means exact-domain matching rules are used. If you use settings or
persistent local data and want to publish a Flash Player 6 SWF file
for Flash Player 7 or 8, you might need to set this value to false
in the ported file. For more information,
When you develop a
series of SWF files that communicate with each other online--for
example, when using loadMovie(), MovieClip.loadMovie(),
MovieClipLoader.LoadClip(), or Local Connection objects--you might
host the SWF files in different domains or in different subdomains
of a single superdomain.
In files published for
Flash Player 5 or earlier, there were no restrictions on
cross-domain or subdomain access.
In files published for
Flash Player 6, you could use the LocalConnection.allowDomain
handler or System.security.allowDomain() method to specify permitted
cross-domain access (for example, to let a file at someSite.com be
accessed by a file at someOtherSite.com), and no command was needed
to permit subdomain access (for example, a file at www.someSite.com
could be accessed by a file at store.someSite.com).
Files published for
Flash Player 7 implement access between SWF files differently from
earlier versions in two ways. First, Flash Player 7 implements
exact-domain matching rules instead of superdomain matching rules.
Therefore, the file being accessed (even if it is published for a
Flash Player version earlier than Flash Player 7) must explicitly
permit cross-domain or subdomain access; this topic is discussed in
this section. Second, a file hosted at a site using a secure
protocol (HTTPS) must explicitly permit access from a file hosted at
a site using an insecure protocol (HTTP or FTP); this topic is
discussed in the next section (see HTTP to HTTPS protocol access
between SWF files).
You usually call
System.security.allowDomain in your applications. However, when the
LocalConnection receiver is an HTTPS SWF file and the sender is not,
allowInsecureDomain is called instead.
The following issue
affects only SWF files published for Flash Player 7. When the
receiver is HTTPS, and the sender is a local SWF file, allowDomain()
is called, even though allowInsecureDomain() should be called.
However, in Flash Player 8, when an HTTPS LocalConnection receiver
is Flash Player 8, and the sender is a local file,
allowInsecureDomain() is called.
Files that run in Flash
Player 8 are subject to changes from how they run in Flash Player 7.
Calling System.security.allowDomain permits cross-scripting
operations only where the SWF file being accessed is the one that
called System.security.allowDomain. In other words, a SWF file that
calls System.security.allowDomain now permits access only to itself.
In previous versions, calling System.security.allowDomain permitted
cross-scripting operations where the SWF file being accessed could
be any SWF file in the same domain as the one that called
System.security.allowDomain. Doing so opened up the entire domain of
the calling SWF file.
Support has been added
for the wildcard (*) value to System.security.allowDomain("*") and
System.security.allowInsecureDomain("*"). The wildcard (*) value
permits cross-scripting operations where the accessing file is any
file and can be loaded from any location (such as global
permission). Wildcard permissions can be useful, but they must
adhere to the new local file security rules in Flash Player 8.
Specifically, local files do not come from a domain, so the wildcard
value must be used. However, use caution when using the wildcard
value because any domain has access to your file. For more
information, see allowInsecureDomain (security.allowInsecureDomain
You might encounter a
situation when you load a child SWF file from a different domain
than the one calling it. You might want to allow that file to script
the parent SWF file, but you don't know the final domain from which
the child SWF file will come. This situation can happen, for
example, when you use load-balancing redirects or third-party
servers. In this situation, you can use the MovieClip._url property
as an argument to this method. For example, if you load a SWF file
into my_mc, you can call System.security.allowDomain(my_mc._url). If
you do this, you must wait until the SWF file in my_mc begins
loading because the _url property does not have its final, correct
value yet. To determine when a child SWF file has started to load,
The opposite situation
can also occur; that is, you might create a child SWF file that
wants to allow its parent to script it, but doesn't know what the
domain of its parent SWF file will be (meaning, it's a SWF file that
might be loaded by a variety of domains). In this situation, call
System.security.allowDomain(_parent._url) from the child SWF file.
You don't have to wait for the parent SWF file to load because it is
loaded before the child file loads.
NOTE : If the
Internet SWF file being accessed is loaded from an HTTPS URL, the
Internet SWF file must call System.security.allowInsecureDomain("*").
The following table
summarizes domain-matching rules in different versions of Flash
Files published for Flash Player
Cross-domain access between SWF files (allowDomain() is needed)
Subdomain access between SWF files
5 or earlier
allowDomain() is needed if superdomains do not match.
7 and later
Exact domain matching
Explicit permission for HTTPS-hosted files to access HTTP- or FTP-hosted files
Exact domain matching
Explicit permission for HTTPS-hosted files to access HTTP- or FTP-hosted files
NOTE : You need
System.security.allowInsecureDomain in Flash Player 7 and later if
you are performing HTTP-to-HTTPS access, even if you have
The versions that
control the behavior of Flash Player are SWF file versions (the
specified Flash Player version of a SWF file), not the version of
Flash Player itself. For example, when Flash Player 8 is playing a
SWF file published for version 7, Flash Player applies behavior that
is consistent with version 7. This practice ensures that player
upgrades do not change the behavior of System.security.allowDomain()
in deployed SWF files.
Because Flash Player 7
and later versions implement exact-domain matching rules instead of
superdomain matching rules, you might have to modify existing
scripts if you want to read them from files that are published for
Flash Player 7 or 8. (You can still publish the modified files for
Flash Player 6.) If you used any LocalConnection.allowDomain() or
System.security.allowDomain() statements in your files and specified
superdomain sites to permit, you must change your parameters to
specify exact domains instead. The following example shows changes
you might have to make if you have Flash Player 6 code:
// Flash Player 6
commands in a SWF file at www.anyOldSite.com
// to allow access by
SWF files that are hosted at www.someSite.com
// or at
commands to allow access by SWF files
// that are published
for Flash Player 7 or later
You might also have to
add statements such as these to your files if you aren't currently
using them. For example, if your SWF file is hosted at
www.someSite.com and you want to allow access by a SWF file
published for Flash Player 7 or later at store.someSite.com, you
must add statements such as the following example to the file at
www.someSite.com (you can still publish the file at www.someSite.com
for Flash Player 6):
In addition, consider
that if a Flash Player 6 application running in Flash Player 7 tries
to access data outside its exact domain, Flash Player 7 and later
domain-matching rules are enforced and the user is prompted to allow
or deny access.
To summarize, you might
have to modify your files to add or change allowDomain statements if
you publish files for Flash Player 7 or later that meet the
cross-SWF file scripting (see Allowing data access between
cross-domain SWF files).
The called SWF file (of
any version) is not hosted at a site using a secure protocol
(HTTPS), or the calling and called SWF files are both hosted at
HTTPS sites. (If only the called SWF file is HTTPS, see HTTP to
HTTPS protocol access between SWF files.)
The SWF files are not
in the same domain (for example, one file is at www.domain.com and
one is at store.domain.com).
You must make the
If the called SWF file
is published for Flash Player 7 or later, include
System.security.allowDomain or LocalConnection.allowDomain in the
called SWF file, using exact domain-name matching.
If the called SWF file
is published for Flash Player 6, modify the called file to add or
change a System.security.allowDomain or LocalConnection.allowDomain
statement, using exact domain-name matching, as shown in the code
examples earlier in this section. You can publish the modified file
for either Flash Player 6 or 7.
If the called SWF file
is published for Flash Player 5 or earlier, port the called file to
Flash Player 6 or 7 and add a System.security.allowDomain statement,
using exact domain-name matching, as shown in the code examples
earlier in this section. (LocalConnection objects aren't supported
in Flash Player 5 or earlier.)
Allowing data access between cross-domain SWF
For two SWF files to
access each other's data (variables and objects), the two files must
originate from the same domain. By default, in Flash Player 7 and
later, the two domains must match exactly for the two files to share
data. However, a SWF file can grant access to SWF files served from
specific domains by calling LocalConnection.allowDomain or
System.security.allowDomain() lets SWF files and HTML files in
specified domains access objects and variables in the SWF file that
contains the allowDomain() call.
If two SWF files are
served from the same domain--for example, http://mysite.com/movieA.swf
and http://mysite.com/movieB.swf--then movieA.swf can examine and
modify variables, objects, properties, methods, and so on in
movieB.swf, and movieB can do the same for movieA. This is called
cross-movie scripting, or cross-scripting.
If two SWF files are
served from different domains--for example, http://mysite.com/movieA.swf
and http://othersite.com/movieB.swf--then, by default, Flash Player
does not allow movieA.swf to script movieB.swf, nor movieB to script
movieA. If you call System.security.allowDomain("mysite.com"),
movieB.swf gives movieA.swf permission to script movieB.swf. A SWF
file gives SWF files from other domains permission to script it by
calling System.security.allowDomain(). This is called cross-domain
For further information
on System.security.allowDomain(), cross-scripting, and cross-domain
scripting, see allowDomain (security.allowDomain method) in the
ActionScript 2.0 Language Reference.
For example, suppose
main.swf is served from www.macromedia.com. That SWF file then loads
another SWF file (data.swf) from data.macromedia.com into a movie
clip instance that's created dynamically using createEmptyMovieClip().
// In macromedia.swf
Suppose that data.swf defines a method named getData() on its main
Timeline. By default, main.swf cannot call the getData() method
defined in data.swf after that file has loaded because the two SWF
files do not reside in the same domain. For example, the following
method call in main.swf, after data.swf has loaded, fails:
// In macromedia.swf,
after data.swf has loaded:
This method call will fail
However, data.swf can grant access to SWF files served from
www.macromedia.com by using the LocalConnection.allowDomain handler
and the System.security.allowDomain() method, depending on the type
of access required. The following code, added to data.swf, allows a
SWF file served from www.macromedia.com to access its variables and
// Within data.swf
this._lockroot = true;
my_lc:LocalConnection = new LocalConnection();
var timestamp:Date =
output_txt.text += "data.swf:"
+ timestamp.toString() + "\n\n";
Now the getData
function in the loaded SWF file can be called by the macromedia.swf
file. Notice that allowDomain permits any SWF file in the allowed
domain to script any other SWF file inthe domain permitting the
access, unless the SWF file being accessed is hosted on a site using
a secure protocol (HTTPS).
Server-side policy files for permitting access to
A Flash document can
load data from an external source by using one of the following data
loading calls: XML.load(), XML.sendAndLoad(), LoadVars.load(),
LoadVars.sendAndLoad(), loadVariables(), loadVariablesNum(),
MovieClip.loadVariables(), XMLSocket.connect(), and Macromedia Flash
Remoting (NetServices.createGatewayConnection). Also, a SWF file can
import runtime shared libraries (RSLs), or assets defined in another
SWF file, at runtime. By default, the data or RSL must reside in the
same domain as the SWF file that is loading that external data or
To make data and assets
in runtime shared libraries available to SWF files in different
domains, you should 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 certain domains, or from all domains. Any SWF file that
is served from a domain specified by the server's policy file is
permitted to access data, assets, or RSLs from that server.
If you are loading
external data, you should create policy files even if you don't plan
to port any files to Flash Player 7. If you are using RSLs, you
should create policy files if either the calling or called file is
published for Flash Player 7.