Specifications

31ADOBE FLEX 3
Building and Deploying Adobe Flex 3 Applications
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 concen-
trate 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
When considering security issues, you cannot think of Flex applications as traditional web applications. Flex
applications 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 a Flex 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 limita-
tions?
The following basic security rules always apply by default:
• Resources in the same security sandbox can always access each other.
• SWF files in a remote sandbox can never access local files and data.
You should consider the following security issues related to the client architecture that affect Flex applications.
Flash Player security features
Much 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 class.
Memory usage and disk storage protections
Flash Player includes security protections for disk data and memory usage on the client computer.