Adobe® Flash® Player
runs applications built as SWF files. Content is delivered as a
series of instructions in binary format to Flash Player over web
protocols in the precisely described SWF (.swf) file format. The
SWF files themselves are typically hosted on a server and then downloaded
to, and displayed on, the client computer when requested. Most of
the content consists of binary ActionScript instructions. ActionScript
is the ECMA standards-based scripting language that Flash uses that
features APIs designed to allow the creation and manipulation of client-side
user interface elements and for working with data.
The Flex security model protects both client and the server.
Consider the following two general aspects to security:
Authorization and authentication of users accessing a
Flash Player operating in a sandbox on the client
Flex supports working with the web application security of any
J2EE application server. In addition, precompiled applications can
integrate with the authentication and authorization scheme of any
underlying server technology to prevent users from accessing your
applications. The Flex framework also includes several built-in
security mechanisms that let you control access to web services,
HTTP services, and server-based resources such as EJBs.
Flash Player runs inside a security sandbox that prevents the
client from being hijacked by malicious application code.
Note: SWF content running in the Adobe® AIR™ follows different security rules than content
running in the browser. For details, see Adobe AIR Security.
Declarative compared to programmatic security
two common approaches to security are declarative and programmatic. Often,
declarative security is server based. Using the server’s configuration,
you provide protection to a resource or set of resources. You use
the container’s authentication and authorization schemes to protect
that resource from unauthorized access.
The declarative approach to security casts a wide net. Declarative
security is implemented as a separate layer from the web components
that it works with. You set up a security system, such as a set
of file permissions or users, groups, and roles, and then you plug
your application's authentication mechanism into that layer.
With declarative security, either a user gains access to the
resource or they do not. Usually the content cannot be customized
based on roles. In an HTML-based application, the result is that
users are denied access to certain pages. However, in a Flex environment,
the typical result of declarative security is that the user is denied
access to the entire application, since the application is seen
as a single resource to the container.
Declarative security lets programmers who write web applications
ignore the environment in which they write. Declarative security
is typically set up and maintained by the deployer and not the developer
of the application. Also, updates to the web application do not
generally require a refactoring of the security model.
Programmatic security gives the developer of the application
more control over access to the application and its resources. Programmatic
security can be much more detailed than declarative security. For
example, a developer using programmatic security can allow or deny
a user access to a particular component inside the application.
Although programmatic security is typically configured by the
developer of the application, it usually interacts with the same
systems as declarative security, so the relationship between developer
and deployer of the application must be cooperative when implementing
Declarative security is recommended over programmatic security
for most applications because the design promotes code reuse, making
it more maintainable. Furthermore, declarative security puts the
responsibility of security into the hands of the people who specialize
in its implementation; application programmers can concentrate on
writing applications and people who deploy the applications in a
specific environment can concentrate on enforcing security policies
and take advantage of that context.
Client security overview
security issues, you cannot think of applications as traditional web
applications. Applications built with Flex often consist of a single
monolithic SWF file that is loaded by the client once, or a series
of SWF files loaded as modules or RSLs. Web applications, on the
other hand, usually consist of many individual pages that are loaded
one at a time.
Most web applications access resources such as web services that
are outside of the client. When an application accesses an external
resource, two factors apply:
Is the user authorized to access this resource?
Can the client load the resource, or is it prevented from
loading the resource, because of its sandbox limitations?
following basic security rules always apply by default:
Resources in the same security sandbox can always access
SWF files in a remote sandbox can never access local files
You should consider the following security issues related to
the client architecture that affect applications.
Flash Player security features
of Flash Player security is based on the domain of origin for loaded
SWF files, media, and other assets. A SWF file from a specific Internet
domain, such as www.example.com, can always access all data from
that domain. These assets are put in the same security grouping,
known as a security sandbox. For example, a SWF file can load SWF
files, bitmaps, audio, text files, and any other asset from its own
domain. Also, cross-scripting between two SWF files from the same
domain is permitted, as long as both files are written using ActionScript
3.0. Cross-scripting is the ability of one SWF file to use ActionScript
to access the properties, methods, and objects in another SWF file.
Cross-scripting is not supported between SWF files written using
ActionScript 3.0 and files using previous versions of ActionScript;
however, these files can communicate by using the LocalConnection
Memory usage and disk storage protections
Player includes security protections for disk data and memory usage
on the client computer.
only type of persistent storage is through the SharedObject class,
which is embodied as a file in a directory whose name is related
to that of the owning SWF file. An application cannot typically
write, modify, or delete any files on the client computer other
than SharedObject data files, and it can only access SharedObject
data files under the established settings per domain.
Player helps limit potential denial-of-service attacks involving
disk space (and system memory) through its monitoring of the usage
of SharedObject classes. Disk space is conserved through limits
automatically set by Flash Player (the default is 100K of disk space
for each domain). The author can set the application to prompt the
user for more disk space, or Flash Player automatically prompts
the user if an attempt is made to store data that exceeds the limit.
In either case, the disk space limit is enforced by Flash Player
until the user gives explicit permission for an increased allotment
for that domain.
Flash Player contains memory and processor
safeguards that help prevent applications from taking control of
excess system resources for an indefinite period of time. For example,
Flash Player can detect an application that is in an infinite loop and
select it for termination by prompting the user. The resources that
the application uses are immediately released when the application
Flash Player uses a garbage collector
engine. The processing of new allocation requests always first ensures
that memory is cleared so that the new usage always obtains only
clean memory and cannot view any previous data.
Privacy is an important aspect of
overall security. Adobe products, including Flash Player, provide
very little information that would reveal anything about a user
(or their computer). Flash Player does not provide personal information about
users (such as names, e-mail addresses, and phone numbers), or provide access
to other sensitive information (such as credit card numbers or account information).
Flash Player does provide is basically standardized hardware and
software configuration information that authors might use to enhance
the user experiences in the environment encountered. The same information
is often available already from the operating system or web browser.
about the client environment that is available to the application includes:
User agent string, which typically identifies the embedding
browser type and operating system of the client
System capabilities such as the language or the presence
of an MP3 decoder (see the Capabilities class)
Presence of a camera and microphone
Keyboard and mouse input
also includes the ability to replace the contents of the client’s Clipboard
by using the setClipboard() method of the System class.
This method does not have a corresponding getClipboard() method,
so protected data that might be stored in the Clipboard already
is not accessible to Flash Player.
sandbox type indicates the type of security zone in which the SWF
file is operating. In Flash Player, all SWF files (and HTML files,
for the purposes of SWF-to-HTML scripting) are placed into one of
four types of sandbox:
files from non-local URLs are placed in a remote sandbox. There
are many such sandboxes, one for each Internet (or intranet) domain
from which files are loaded.
The default sandbox for local files. SWF
files in this sandbox may not contact the Internet (or any servers)
in any way—they may not access network endpoints with addresses
such as HTTP URLs.
SWF file in this sandbox may communicate
over the network but may not read from local file systems.
sandbox is not restricted. Any local file can be placed in this sandbox
if given authorization by the end user. This authorization can come
in two forms: interactively through the Settings Manager or noninteractively through
an executable installer that creates Flash Player configuration
files on the user’s computer.
You can determine the current
sandbox type by using the sandboxType property
of the Security class,
as the following example shows:
The executing SWF file for the previous example is shown below:
When you compile an application,
you have some control over which sandbox the application is in.
This determination is a combination of the value of the use-network compiler
option (the default is true) and whether the SWF
file was loaded by the client over a network connection or as a
The following table shows how the sandbox
type is determined:
n/a (causes an error)
Flash Player clients can be one of the following four types:
Embedded Flash Player
Debugger version of embedded Flash Player
Stand-alone Flash Player
Debugger version of stand-alone Flash Player
The stand-alone Flash Player runs on the desktop. It is typically
used by people who are running applications that are installed and
maintained by an IT department that has access to the desktop on
which the application runs.
The embedded Flash Player is run within a browser. Anyone with
Internet access can run applications from anywhere with this player.
For Internet Explorer, the embedded player is loaded as an ActiveX
control inside the browser. For Netscape-based browsers (including
Firefox), it is loaded as a plug-in inside the browser. Using an
embedded player lets the developer use browser-based technologies
such as FORM and BASIC authentication as well as SSL.
Applications hosting the Flash Player ActiveX
control or Flash Player plug-in can use the EnforceLocalSecurity
and DisableLocalSecurity API calls to control security settings.
If DisableLocalSecurity is opened, the application does not benefit
from the local-with-networking and local-with-file-system sandboxes.
All files loaded from the local file system are placed into the
local-trusted sandbox. The default behavior for an ActiveX control
hosted in a client application is DisableLocalSecurity.
If EnforceLocalSecurity is opened, the application can use all
three local sandboxes. The default behavior for the browser plug-in
is when a SWF file communicates directly with another SWF file. This
communication includes calling methods and setting properties of
the other SWF file.
SWF file loading and cross-scripting are always permitted between
SWF files that reside in the same sandbox. For example, any local-with-filesystem
SWF file can load and cross-script any other local-with-filesystem
SWF file; any local-with-networking SWF file can load and cross-script
any other local-with-networking SWF file; and so on. The restrictions
appear when two SWF files from different sandboxes or two remote
SWF files with different domains attempt to cooperate.
For SWF files in the remote sandbox, if two SWF files were loaded
from the same domain, they can cross-script without any restrictions.
If both SWF files were loaded from a network, but from different
domains, you must provide permissions to allow them to cross-script.
To enable cross-scripting
between SWF files, use the Security class’s allowDomain() and allowInsecureDomain() methods.
You call these methods from the called SWF file and specify the
calling SWF file’s domain. For example, if SWF1 in domainA.com calls
a method in SWF2 in domainB, SWF2 must call the allowDomain() method
and specifically allow SWF files from domainA.com to cross-script
the method, as the following example shows:
You use the ExternalInterface API
to let your application call scripts in the wrapper and to allow
the wrapper to call functions in your application. The ExternalInterface
API consists primarily of the call() and addCallback() methods
in the flash.net package.
This communication relies on the domain-based
security restrictions that the allowScriptAccess and allowNetworking properties
define. You set the values of the allowScriptAccess and allowNetworking properties in
the SWF file’s wrapper. For more information, see About the object and embed tags.
By default, the application and the HTML page it is calling must
be in the same domain for the call() method to
succeed. For more information, see Communicating with the wrapper.
The navigateToURL() method
The navigateToURL() method
opens or replaces a window in the Flash Player’s container application.
You typically use it to launch a new browser window, although you
can also embed script in the method’s call to perform other actions.
usage of the navigateToURL() method relies on the
domain-based security restrictions that the allowScriptAccess and allowNetworking parameters
define. You set the values of the allowScriptAccess and allowNetworking parameters
in the SWF file’s wrapper. For more information, see About the object and embed tags.
reside entirely on the client. If the browser loads the application,
the application SWF file, plus externally loaded images and other
media files, are stored locally on the client in the browser’s cache.
These files reside in the cache until cleared.
Storing a SWF file in the browser’s cache can potentially expose
the file to people who would not otherwise be able to see it. The
following table shows some example locations of the browser’s cache
Browser or operating system
Internet Explorer on Windows XP
C:\Documents and Settings\username\Local
Settings\Temporary Internet Files
Firefox on Windows XP
C:\Documents and Settings\username\Application
These files can remain in the cache even after the browser is
To prevent client browsers from caching the
SWF file, try setting the following HTTP headers in the SWF file’s
Note that in some cases, setting the Pragma header
to "no-cache" can cause a runtime error with GET
requests over SSL with the HTTPService class. In this case, setting
just the Cache-control header should work.
Marc Speck has a blog entry that describes the issue
and presents several solutions.
Trusted sites and directories
browser security model includes levels of trust applied to specific
websites. Flash Player interacts with this model by assigning a
sandbox based on whether the browser declared the site of the SWF
file’s origin trusted.
If Flash Player loads a SWF file from a trusted website, the
SWF file is put in the local-trusted sandbox. The SWF file can read
from local data sources and communicate with the Internet.
You can also assign a SWF file to be in the local-trusted sandbox
when you load it from the local file system. To do this, you configure
a directory as trusted by Flash Player (which results in the SWF
file being put in the local-trusted sandbox) by adding a FlashPlayerTrust
configuration file that specifies the directory to trust. This requires
administrator access privileges to the client system, so it is typically
used in controlled environments. Users can also define a directory
as trusted by using the Flash Player User Settings Manager. For
more information, see the Flash Player documentation.
Deploying secure applications
you deploy an application, you make the application accessible to
your users. The process of deploying an application is dependent
on your application, your application requirements, and your deployment
environment. You can employ some of the following strategies to
ensure that the application you deploy is secure.
Deploying local SWF files versus network SWF files
Client computers can obtain individual
SWF files from a number of sources, such as from an external website
or a local file system. When SWF files are loaded into Flash Player,
they are individually assigned to security sandboxes based on their origin.
Player classifies SWF files downloaded from the network (such as
from external websites) in separate sandboxes that correspond to
their website origin domains. By default, these files are authorized
to access additional network resources that come from the specific
(exact domain name match) site. Network SWF files can be allowed
to access additional data from other domains by explicit website
and author permissions.
A local SWF file describes any file
referenced by using the “file” protocol or a UNC path, which does
not include an IP address or a qualifying domain. For example, “\\test\test.swf”
and “file:\test.swf” are considered local files, while “\\test.com\test.swf”
and “\192.168.0.1\test.swf” are not considered local files.
Local SWF files from local origins, such
as local file systems or UNC network paths, are placed into one
of three sandboxes: local-with-networking, local-with-filesystem,
When you compile the application, if you
set the use-network compiler option to false,
local SWF files are placed in the local-with-filesystem sandbox. If
you set the use-network compiler option to true,
local SWF files are placed in the local-with-networking sandbox.
SWF files that are registered as trusted (by users or by installer
programs) are placed in the local-trusted sandbox. Users can also
reassign (move) a local SWF file to or from the local-trusted sandbox
based on their security considerations.
Before you deploy your application, ensure that
your proxy servers, firewalls, and assets are configured properly.
Adobe provides a deployment checklist that you can follow. For more
information, see Deployment checklist.
your application relies on assets loaded from another domain, and
that domain has a crossdomain.xml file on it, remove wildcards from
that file if possible. For example, change the following:
Also, set the value
of the to-ports attribute of the allow-access-from tag to
ensure that you are only allowing necessary ports access to the
Check your application for calls to the allowDomain() and allowInsecureDomain() methods.
During development, you might pass these methods a wildcard character
(*), but now restrict those methods to allowing requests only from
the necessary domains.
Deploy assets to WEB-INF
some deployments, you want to make assets such as data files accessible
to the application, but not accessible to anyone requesting the
file. If you are using a J2EE-based server, you can deploy those
files to a subdirectory within the WEB-INF directory. Based on J2EE
security constraints, no J2EE server can return a resource from
the WEB-INF directory to any client request. The only way to access files
in this directory is with server-side code.
Twitter™ and Facebook posts are not covered under the terms of Creative Commons.