Specifications

CHAPTER 3

}

]]></mx:Script>

<mx:Button id="b1" label="Click Me To Trigger Security Error"

click="triggerSecurityError()"/>

</mx:Application>

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” on page 233.

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.

Using passwords

Using passwords in your Flex application is a common way to protect resources from unauthorized access. Test

the validity of the password on the server rather than the client, because the client has access to all the logic in the

local SWF file.

Never store passwords locally. For example, do not store username and password combinations in local Share-

dObjects. These are stored in plain-text and unencrypted, just as cookie files are. Anyone with access to the user’s

computer can access the information inside a SharedObject.