ACTIONSCRIPT 3 Developer’s Guide en

ACTIONSCRIPT 3.0 DEVELOPER’S GUIDE
Security
Unless there are administrator restrictions to the user's computer, AIR applications are privileged to write to any
location on the user's hard drive. Developers are advised to use the app-storage:/ path for local storage related to
their application. Files written to app-storage:/ from an application are put in a standard location:
On Mac OS: the storage directory of an application is //Local Store/ where is
the user's preferences folder. This is typically /Users//Library/Preferences
On Windows: the storage directory of an application is \\Local Store\ where is
the user's CSIDL_APPDATA Special Folder. This is typically C:\Documents and
Settings\\Application Data
On Linux: //Local Store/where is /home//.appdata
If an application is designed to interact with existing files in the user's file system, be sure to read “Best security
practices for developers” on page 1080.
Working securely with untrusted content
Adobe AIR 1.0 and later
Content not assigned to the application sandbox can provide additional scripting functionality to your application, but
only if it meets the security criteria of the runtime. This topic explains the AIR security contract with non-application
content.
Security.allowDomain()
Adobe AIR 1.0 and later
AIR applications restrict scripting access for non-application content more stringently than the Flash Player browser
plug-in restricts scripting access for untrusted content. For example, in Flash Player in the browser, when a SWF file
that is assigned to the local-trusted sandbox calls the System.allowDomain() method, scripting access is granted
to any SWF loaded from the specified domain. The analogous approach is not permitted from application content
in AIR applications, since it would grant unreasonable access unto the non-application file into the user's file system.
Remote files cannot directly access the application sandbox, regardless of calls to the Security.allowDomain()
method.
Scripting between application and non-application content
Adobe AIR 1.0 and later
AIR applications that script between application and non-application content have more complex security
arrangements. Files that are not in the application sandbox are only allowed to access the properties and methods of
files in the application sandbox through the use of a sandbox bridge. A sandbox bridge acts as a gateway between
application content and non-application content, providing explicit interaction between the two files. When used
correctly, sandbox bridges provide an extra layer of security, restricting non-application content from accessing object
references that are part of application content.
The benefit of sandbox bridges is best illustrated through example. Suppose an AIR music store application wants to
provide an API to advertisers who want to create their own SWF files, with which the store application can then
communicate. The store wants to provide advertisers with methods to look up artists and CDs from the store, but also
wants to isolate some methods and properties from the third-party SWF file for security reasons.
Last updated 6/6/2012
1079