There are two areas of security in Communication applications that you need to consider:
The security of runtime environment (Flash Player 6 and the Flash Communication Server, specifically)
The security of the application
You will be happy to know that Macromedia provides an environment that is as secure as it can be. The term "secure," however, needs to be put in context.
You can find independent security assessments from @Stake and reviews on both Flash Player 6 and the Flash Communication Server on the Macromedia web site (http://www.macromedia.com/software/flash/whitepapers/).
Users should be confident that the applications running within the Flash Communication Server and Flash player environment will not compromise the integrity of the local client or their server operating systems. Neither technology has an ActionScript interface to directly interact with the server or client operating system. Sandbox security using domain-oriented controls are in place within the Flash player and the Communication Server to prevent cross-site scripting that could jeopardize the integrity of the content within these environments. The environments are secure, but it is your responsibility to ensure the integrity of access and transmission. Let's take a look at these security points separately.
Transmission security handles the accessibility of data while it is being transported from server to client or from client to server. If you plan to use the Flash Communication Server to share data that is confidential or secure, you should know that the RTMP protocol cannot be encrypted in its 1.0 release. Wrong-doers who can "sniff" the port can gain access to the data during transmission, as they can to nonencrypted email or web pages.
This security hole does not limit your ability to use the Flash Communication Server. You can communicate with full encryption between the client and a Flash Remoting MX-enabled server, such as Macromedia ColdFusion MX or ASP.NET. If you have control over a secure network, such as a VPN, you can deploy Communication application over the trusted domain.
Consider a simple username and password authentication script. A user enters a login and password in the Flash interface. If the player sends that login and password directly to the Flash Communication Server over RTMP, it will be sent in AMF format over an unencrypted connection that could be compromised.
If the Flash player sends the login and password through an encrypted HTTPS connection directly to a Flash Remoting MX-enabled application server, a ticketing-type system could be built, where the server would issue a key to the Flash player if the credentials supplied are accepted. This key could then be passed openly to the Communication Server. The Communication Server will confirm the key with the application server and accept or deny the connection based on the response from the application server. No username or password is transmitted insecurely during this process.
Clearly security could be a book unto itself. Developing a security practice is unique to everyone's environment and experience. Your organization might be governed to implement standard security practices and procedures into everything it builds. You might also have a custom practice of implementing security. It is important to be aware of security responsibilities and where you can restrict users entering or listening in to your application.
Published SWF movies are not protected and can be opened by non-Macromedia software. Their ActionScript should not be considered secure, because it can be exposed to potential wrong-doers. You should avoid placing sensitive authentication processes within the Flash client. Always use Flash Remoting MX or the Communication Server to handle authentication to the Flash interface, and never store sensitive data within the Flash movie.
The official word from Macromedia SWF security is:
"There are third-party tools available that allow users to edit a rendered SWF to a certain degree, as well as remove the protection tags if an author has accidentally lost their work and needs to reimport the SWF. These tools are not made by Macromedia and carry no guarantees. In addition, they are only mentioned in the context of helping authors regain their own work; the potential for abuse still remains." ?Technote: 4109, macromedia.com
To address this issue, third-party (non-Macromedia) ActionScript obfuscators on the market add additional protection to your scripts. A great one can be found at http://www.genable.com/aso/. This software will not encrypt the ActionScript, but it will make it unreadable by human eyes, if it is accessed.
Now that you are aware of some of your security responsibilities, let's move on to some ActionScript techniques.