Use some of the following techniques to try to make your use of ActionScript more secure.

Handling errors

The SecurityError exception is thrown when some type of security violation takes place. Security errors include:

• An unauthorized property access or method call was made across a security sandbox boundary.
• An attempt was made to access a URL not permitted by the security sandbox.
• A socket connection was attempted to an unauthorized port number, for example, a port below 1024, without a policy file present.
• An attempt was made to access the user's camera or microphone, and the request to access the device was denied by the user.

Flash Player dispatches SecurityErrorEvent objects to report the occurrence of a security error. Security error events are the final events dispatched for any target object. This means that any other events, including generic error events, are not dispatched for a target object that experiences a security error.

Your event listener can access the SecurityErrorEvent object's text property to determine what operation was attempted and any URLs that were involved, as the following example shows:

<?xml version="1.0"?>
<!-- security/SecurityErrorExample.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="initApp()">
    <mx:Script><![CDATA[
        import flash.net.URLLoader;
        import flash.net.URLRequest;
        import flash.events.SecurityErrorEvent;
        import mx.controls.Alert;

        private var loader:URLLoader = new URLLoader();

        private function initApp():void {
            loader.addEventListener(SecurityErrorEvent.SECURITY_ERROR, securityErrorHandler);
        }
        
        private function triggerSecurityError():void {      
            // This URL is purposefully broken so that it will trigger a
            // security error.
            var request:URLRequest = new URLRequest("http://www.[yourDomain].com");
            
            // Triggers a security error.
            loader.load(request);
        }

        private function securityErrorHandler(event:SecurityErrorEvent):void {
            Alert.show("A security error occurred! Check trace logs for details.");         
            trace("securityErrorHandler: " + event.text);
        }
    ]]></mx:Script>

    <mx:Button id="b1" label="Click Me To Trigger Security Error" click="triggerSecurityError()"/>

</mx:Application>
The executing SWF file for the previous example is shown below:

If no event listeners are present, the debugger version of Flash Player automatically displays an error message that contains the contents of the text property.

In general, try to wrap methods that might trigger a security error in a try/catch block. This prevents users from seeing information about destinations or other properties that you might not want to be visible.

Suppressing debug output

Flash Player writes debug output from a trace() method or the Logging API to a log file on the client. Any client can be running the debugger version of Flash Player. As a result, remove calls to the trace() method and Logging API calls that produce debugging output so that clients cannot view your logged information.

If you use the Logging API in your custom components and classes, set the value of the LogEventLevel to NONE before compilation, as the following example shows:

myTraceTarget.level = LogEventLevel.NONE;

For more information about the Logging API, see Using the logging API.

Using host-based authentication

IP addresses and HTTP headers are sometimes used to perform host-based authentication. For example, you might check the Referer header or the client IP address to ensure that a request comes from a trusted source.

However, request headers such as Referer can be spoofed easily. This means that clients can pretend to be something they are not by settings headers or faking IP addresses. The solution to the problem of client spoofing is to not use HTTP header data as an authentication mechanism.