Security changes in Flash Player 7

Note: This article describes the security features in Flash Player 7,0,19,0. It is intended for historical purposes only. To remain up to date about Flash security, please read the latest security documents in the Flash Player Developer Center.

Overview of the Security Changes

Two restrictions to the Flash security model were added, starting with Flash Player 7:

• All operations require an exact domain match. Similar domains, such as www.mysite.com and store.mysite.com, are no longer considered a match. Domains must now match exactly.
• Flash SWF files served over HTTP (or other insecure protocols) are no longer allowed to access movies or data served over HTTPS.

In addition, we added a new permission mechanism which allows broader cross-domain cooperation. You can perform data loading (loadVariables, XML, XMLSocket, runtime shared libraries, Flash Remoting) from outside a movie's own domain as long as the server providing the data provides a policy file—a small XML file that grants cross-domain loading permissions.

Additional Changes in Flash Player 7r19

Flash Player 7r19 added the ActionScript API System.security.loadPolicyFile. Using this API, you can place policy files in arbitrary locations, rather than just the default location at the server root. With this API, you can also serve policy files directly from XMLSocket servers and specify XMLSocket connections to ports below 1024.

There are two areas where a Flash movie can retrieve other documents from a URL:

• Movie loading: A Flash movie loads another Flash movie using the ActionScript method MovieClipLoader.LoadClip, loadMovie, or loadMovieNum.
• Data loading: A Flash movie retrieves some other form of data, such as loading an XML document, retrieving the output of a loadVariables script, or connecting to an XMLSocket server.

Flash Player enforces certain cross-domain restrictions for these operations. All cross-domain restrictions compare the URL of the Flash movie making the request with the URL it requests. If the two URLs come from the same domain, Flash Player permits the operation. With movie loading, Flash Player always permits the actual loadMovie operation, but if the URLs of the loading and loaded movie do not come from the same domain, then it does not allow the two movies to interact with each other's ActionScript variables and methods. Data loading operations work differently; if the domains do not match, Flash Player does not permit the operation at all.

Domain matching changes

Flash Player 6 compared domains using superdomains. The superdomain of a domain is a similar domain that has the first component removed. For example, the superdomain of www.mysite.com is mysite.com.

Flash Player 6 considered the domains www.mysite.com and store.mysite.com to be a match. A movie served from http://www.mysite.com/myMovie.swf could use ActionScript to interact with another movie loaded with the loadMovie method from http://store.mysite.com/anotherMovie.swf, or download an XML file from http://store.mysite.com/myData.xml.

In Flash Player 7, however, www.mysite.com and store.mysite.com are not a match. The only domains that match are those that are identical—for example, www.mysite.com and www.mysite.com. The earlier examples are no longer permitted. You can modify the default Flash Player security rules using permission mechanisms, which this article explains in further detail.

Note that web browsers have required exact domain matching for some time.

Protocol matching changes

In Flash Player 6, domains were the only aspects of URLs that the Flash Player examined. This meant that, for example, a movie served from http://www.mysite.com/myHttpMovie.swf could use ActionScript to interact with another movie loaded with loadMovie from https://www.mysite.com/mySecureMovie.swf, or download an XML file from https://www.mysite.com/mySecureData.xml.

In Flash Player 7, a movie served over a nonsecure protocol, such as HTTP, cannot access other documents served over the secure HTTPS protocol, even when those documents come from the same domain. This means that the above examples are no longer permitted by default.

You can modify the default Flash Player security rules by using permission mechanisms, which this article explains in further detail. However, we recommend against overriding the default HTTPS protection because doing so weakens the security offered by HTTPS.

HTTPS restriction is asymmetrical; movies served over HTTPS can access other documents served over insecure protocols.

Note that web browsers have protected HTTPS documents in the same way for some time.

This section describes the only change that can prevent existing Flash content from working as intended.

The security restrictions affect all data-loading operations:

• loadVariables, loadVariablesNum, MovieClip.loadVariables, LoadVars.load, LoadVars.sendAndLoad
• XML.load, XML.sendAndLoad
• XMLSocket.connect
• Symbol importing from runtime shared libraries
• Flash Remoting (NetServices.createGatewayConnection)

In Flash Player 7, these operations will fail under the following conditions:

• When they reference a URL that is outside the exact domain of the movie that makes a request
• When they reference an HTTPS URL where the movie that makes the request is not served over HTTPS

For most of these operations, the new rules apply regardless of the movie's published version. For runtime shared libraries, however, the new rules apply only if either the importing movie or library movie (or both) are made for Flash Player 7.

Fallback dialog box

If a movie made for Flash Player 6 or earlier makes a forbidden data-loading request, and the request would have been permitted in Flash Player 6, the request does not completely fail. Instead, Flash Player displays a dialog box to the user (see Figure 1).

If the user clicks Allow, the request succeeds. If the user clicks Deny, the request fails. If the movie that makes the request is too small to display the dialog box (if the movie is smaller than 215 x 138 pixels), the dialog box does not appear and Flash Player acts as though the user had clicked Deny.

If the user selects "Never ask again," Flash Player remembers their answer and applies it to all movies that prompt the dialog box, even those movies that are too small to display the dialog box.

Determining if the new restrictions affect your movies

For movies that are 215 x 138 pixels or larger, test your movie using Flash Player 7. If the new rules adversely affect your movie, the above dialog box will appear.

However, if you have at some time chosen "Never ask again," or if your movie is smaller than 215 x 138 pixels, the dialog box will not appear. In these situations, you can do the following:

1. Install a Debug version of a Flash Player 7 browser player (plug-in or ActiveX control).
2. Determine the logging location for Flash Player. In Mac OS X, the logging location is /Library/Application Support/Macromedia. In Mac Classic, it is Application Support:Macromedia under your System folder. In Windows, the location varies and your HOMEDRIVE and HOMEPATH environment variables determine the location. Go to a command prompt and type echo %HOMEDRIVE% and echo %HOMEPATH%.
3. Create a text file in this directory called mm.cfg. Write the following line in this file:

   SecurityDialogReportingEnable = true

4. Test your movie in a browser.
5. Look for a file alongside mm.cfg called flashlog.txt. If this file does not exist, the new rules do not affect your movie. If flashlog.txt exists, open it. If your movie is affected, a line similar to the following will appear in the file:

Fixing problems in your existing movies

Once you determine that exact domain matching affects one of your existing movies, you can easily make your movie function again as intended. Create a policy file on the server that your movie is trying to access. Read more about policy files in the next section.

Here is a brief overview of the steps:

1. Determine the server from which your movie is trying to load data. Follow the steps in the previous section about mm.cfg to identify a particular server. In the example in that section, the server was store.mysite.com. If your movie accesses an XMLSocket server, you must create the policy file on an HTTP server on port 80 of the same domain as the XMLSocket server. You can tell when your movie accesses an XMLSocket server because the dialog box reports "[domain]:[port]" instead of just "[domain]" and flashlog.txt reports "[domain]:[port]" instead of a full URL.
2. Create a file in the document root directory of the server and name it crossdomain.xml.
3. Copy the following text into crossdomain.xml:

4. For the value of the domain attribute in the <allow-access-from> tag, enter the exact domain of the movie making the request. In our example, that domain would be www.mysite.com.
5. If the HTTPS restriction affects your movie—that is, a non-HTTPS server serves the movie, but the movie downloads data from an HTTPS server—add the secure="false" attribute to your <allow-access-from> tag, as in the following example:
   <allow-access-from domain="www.mysite.com" secure="false" />
6. If you have movies from additional domains that must access the server where you have created the policy file, add an <allow-access-from> tag for each necessary domain.
7. If you have other servers that your movies access to load data, create a policy file for each of those servers.

After you follow these steps, all problems with your existing movies should be resolved. The remainder of this article applies only to new movies targeting Flash Player 7 or to older movies that you are upgrading for Flash Player 7.

Writing policy files for new movies

Policy files are a great tool for solving problems with existing content, as you saw above. But that isn't their only purpose. Policy files are a general-permission mechanism, a way for a server to declare that the documents it serves should be available to Flash movies from certain domains, or from all domains. If you're familiar with the System.security.allowDomain method in ActionScript (see the section Granting Cross-Movie Scripting Permissions), think of policy files as an equivalent mechanism, but one that governs data-loading operations, rather than ActionScript access between movies.

For example, policy files can be useful when you have a public XML feed that describes transit timetables or the contents of a weblog. By creating an all-domains policy file, you enable any Flash developer to create Flash movies that load your XML data directly without requiring any kind of server-side proxy.

Policy file basics

Whenever Flash Player 7 detects an out-of-domain data-loading request, the player tries to find a policy file on the server from which it attempts to load data. If a policy file exists and it grants access to the origin domain of the Flash movie making the request, then the operation succeeds.

Flash Player can find a policy file in two ways:

• A movie can tell the player where to find a policy file by calling System.security.loadPolicyFile
• The player can look in the default location, /crossdomain.xml.

Compare the two techniques in the table below:

It is easier to use the default location technique for the following reasons:

• It opens up the entire server.
• It is compatible with all versions of Flash Player 7 and above.
• It doesn't require movies to say anything about policy files.

However, sometimes you may find it inconvenient to place a file in a root location on your server, or you may need to serve a policy file from an XMLSocket server. In these cases, you should use the loadPolicyFile technique.

Call System.security.loadPolicyFile to specify the location of a policy file for Flash Player. Thereafter, the Flash Player will use that policy file whenever your movie makes a data-loading request for a URL that falls within the scope of the policy file—that is, when the data-loading URL matches the policy file URL up to and including the directory in which the policy file resides. You can make multiple calls to System.security.loadPolicyFile, and their scopes may even overlap; the Flash Player will always allow a request as long as one or more in-scope policy files permit it. The Flash Player will always wait for any pending loadPolicyFile downloads to complete before accepting or rejecting a data-loading request; therefore, you may call loadPolicyFile immediately followed by your data-loading request without worrying about asynchronous timing. (One exception, however, is runtime shared libraries; see below.) As a final fallback, if you make a data-loading request that any already-loaded policy file cannot authorize, the Flash Player will attempt to retrieve a policy file from the default location, /crossdomain.xml.

Here is an example of calling loadPolicyFile:

Note that the above policy file authorizes the retrieval of data from any URLs that begin with http://www.mysite.com/flash/, but not from other areas of www.mysite.com.

A default policy file must reside at the location /crossdomain.xml—that is the only location that Flash Player checks automatically. You must place a default policy file in the root directory of the server's document space and you must name it crossdomain.xml.

A policy file controls access for the server it resides upon, no matter how a movie contacts that server. The same policy file can handle requests to a variety of different URLs that resolve to the same server. For example, a Flash movie might try to load data from your server based on its IP address, any of several domain names that resolve to the same server, or different protocols (such as HTTP and HTTPS) that are actually handled by the same server.

Normally, Flash Player looks for a default policy file on the server where the movie requests data. There is one exception, however. When a movie attempts to connect to an XMLSocket outside its domain, and there is no xmlsocket:// policy file to authorize the connection (see below), Flash Player looks for a policy file on an HTTP server on port 80 in the domain where the request attempts the connection.

Policy files work for any version of Flash movies. However, policy files are only effective when you play movies in Flash Player 7.

Flash Player will ignore any policy file that is served using a cross-domain redirect. For example, if the Flash Player request for http://www.mysite.com/crossdomain.xml redirects to http://elsewhere.mysite.com/crossdomain.xml, Flash Player will ignore that policy file. Be sure not to use cross-domain redirects to serve policy files. (Redirects within the same domain are allowed.)

The security fallback dialog box (discussed earlier) only appears when a movie made for Flash Player 6 or earlier tries a cross-domain operation that Flash Player 6 would have allowed and when a policy file doesn't exist on the server providing the data. In other words, as soon as you provide a policy file on a server, users will no longer see the fallback dialog box when movies attempt to download data from that server. Don't use the dialog box to let users override the Flash security model; it is only intended to permit older movies to continue working until their maintainers have a chance to create policy files. Once there is a policy file, the dialog box is no longer necessary: The policy file either authorizes the operation or it doesn't. The dialog box never appears for movies made for Flash Player 7 because you're developing and testing those movies in situations where the new, stricter security rules are already understood and where you're putting policy files in place before you deploy the movies.

If you call loadPolicyFile, ensure that you call it prior to any operations that require the policy file you are loading. This can be especially tricky when you are using loadPolicyFile to authorize cross-domain RSLs (runtime-shared libraries). You must call loadPolicyFile at least one frame before the first time you use a symbol from the RSL. For example, let's say you have a movie at http://www.mysite.com/myMovie.swf, and in myMovie.swf at frame 15, you import a symbol called airplane_mc from http://www.myothersite.com/assets/airplane.swf, and you have a policy file at http://www.myothersite.com/assets/policy.xml. You must be sure that you call System.security.loadPolicyFile ("http://www.myothersite.com/assets/policy.xml") in the actions for frame 14 or earlier. This means that it is impossible to use loadPolicyFile to authorize usage of symbols in frame 1; the earliest you could use RSL symbols, authorized by loadPolicyFile, is in frame 2; you would have to call loadPolicyFile in frame 1.

Policy file syntax

Policy files must be in XML format. You may include XML comments:

Policy files always consist of a single <cross-domain-policy> tag that includes zero or more <allow-access-from> tags. Each <allow-access-from> tag has one required attribute, called domain, which specifies a domain from which you want to permit access. The value of domain can be any of the following:

• An exact domain name, such as www.mysite.com.
• An exact IP address, such as 65.57.83.12. This only gives movies access when they are explicitly loaded from that IP address. It does not give movies access when they load using domain names that just happen to resolve to that IP address.
• A wildcard domain name, such as *.mysite.com. These wildcards must always begin with an asterisk followed by a dot, and they must not contain asterisks anywhere except at the beginning. The characters after the dot are the suffix that matches. The wildcard *.mysite.com permits access to Flash movies loaded from any domain that ends in .mysite.com, such as www.mysite.com, store.mysite.com, or longer.subdomain.mysite.com. As a special case, the wildcard also permits the domain mysite.com—that is, without the subdomain.
• A pure wildcard: * (a single asterisk). This allows access from all domains and IP addresses.

Each <allow-access-from> tag may contain the secure attribute, which has two possible values, true and false. The default value is true. When you specify secure="false", you allow access by movies served over protocols other than HTTPS. This only affects policy files that reside on HTTPS servers.

We recommend against using secure="false" because allowing non-HTTPS documents to access HTTPS data can compromise HTTPS security. Instead, we recommend that you serve over HTTPS all Flash movies that require access to HTTPS data. However, if using HTTPS for all of your documents is prohibitively expensive or impractical, secure="false" will override Flash Player's default HTTPS protection.

If a policy file has no <allow-access-from> tags, it serves as an explicit deny-all policy file. The only difference between a deny-all policy file and no policy file at all is that movies made for Flash Player 6 or earlier won't display the fallback dialog box when they try to load data from a server that has a deny-all policy file.

Here is an example of a policy file:

XMLSocket policy files

Prior to version 7r19, XMLSockets suffered from two security limitations. First, policy files authorizing XMLSocket operations could only come from an HTTP server on port 80 in the same domain as the XMLSocket server. This is sometimes inconvenient, because sometimes you may have an XMLSocket server in a domain where there is no reason to set up an HTTP server, except to serve policy files. Secondly, XMLSocket connections have historically been limited to server ports of 1024 and above. You can overcome both of these limitations, however, using XMLSocket policy files.

Starting with version 7r19, the Flash Player supports the ActionScript API System.security.loadPolicyFile. There is a special syntax you can use to retrieve a policy file directly from an XMLSocket server:

With this command, Flash Player will attempt to connect to an XMLSocket server at socks.mysite.com, port 123, and download an XMLSocket policy file. This policy file may permit XMLSocket connections to all ports on the XMLSocket server or only to certain ports. If the policy file permits access from the origin domain of the movie, and includes port 456 in the range of ports available to that domain, then the XMLSocket.connect request above will succeed.

A policy file served by an XMLSocket server has the same syntax as any other policy file, except that it must also specify the ports to which it grants access. When a policy file comes from a port less than 1024, it may grant access to any ports; when a policy file comes from port 1024 or higher, it may only grant access to ports 1024 and higher. The allowed ports are specified in a to-ports attribute in the <allow-access-from> tag. Single port numbers, port ranges, and wildcards are accepted values. Here is an example XMLSocket policy file:

A policy file obtained from the default location ( /crossdomain.xml on an HTTP server on port 80) implicitly authorizes XMLSocket access to all ports 1024 and above. There is no way to retrieve a policy file to authorize XMLSocket operations from any other location on an HTTP server; any custom locations for XMLSocket policy files must be on an XMLSocket server.

To connect an XMLSocket to a port lower than 1024, you must always first load a policy file with loadPolicyFile, even when your movie connects to its own exact domain.

Here is the sequence of how the player downloads XMLSocket policy files:

1. Upon establishing a connection with the specified port, the Flash Player transmits <policy-file-request/>, terminated by a null byte.
2. You may configure an XMLSocket server to serve both policy files and normal XMLSocket connections over the same port, in which case, the server should wait for <policy-file-request/> before transmitting a policy file.
3. You may also set up a server to serve policy files over a separate port from normal connections, in which case, it may send a policy file as soon as the player establishes a connection on the dedicated policy file port.
4. The server must send a null byte to terminate a policy file and may then close the connection; if the server does not close the connection, the Flash Player will do so upon receiving the terminating null byte.

If you are using a third-party XMLSocket server, check with your server vendor to see if your server includes support for policy files, or if a future release will add support for policy files.

Are policy files safe?

Policy files grant cross-domain permissions. They permit operations that would not be permitted by default. It is important to understand what a policy file enables, rather than simply regarding the default rules as a barrier and creating a policy file that accomplishes your task without considering the consequences.

When you specify a domain in a policy file, you declare that you are willing to allow the operators of any servers in that domain to obtain any document on the server where the policy file resides. Often this is exactly what you want. For example, if you serve only public documents from a particular server, you should have no qualms about who can obtain documents on that server because anyone can simply visit your server and download files they want. In this situation, it is safe to open your server to all domains:

On the other hand, if you serve private documents or anything that requires some form of authentication, such as a password, or if your server is behind a firewall, where only certain users can access it, then it is risky to put a public policy file on that server. Doing so would enable Flash movies to download documents from your server whenever they run on the computers of users that your server trusts. These Flash movies could potentially reveal private data from your server to people whom you do not trust.

If you need to create a policy file in such a situation, it is best to permit access for domains that you specifically know need access. For example, if you run a server at bigbang.staticland.net that provides XML data and you serve Flash movies from www.bigbang-corp.com, which needs to load the XML data, put a policy file on bigbang.staticland.net that enables access specifically from www.bigbang-corp.com.

If you run a server that serves especially sensitive documents and you know there are no Flash movies under your control that need to access those documents, it is safest to create a deny-all policy file on that server:

Cross-movie scripting occurs when one Flash movie loads another Flash movie using MovieClipLoader.LoadClip, loadMovie, or loadMovieNum, and then one of the movies uses ActionScript to examine or modify variables in the other movie, or calls functions or methods in the other movie. By default, cross-movie scripting is only permitted with movies that come from the same domain. Movies are always allowed to load other movies from anywhere they wish but security restrictions may prevent those movies from communicating with each other.

Cross-movie scripting also occurs when an HTML page uses JavaScript (or another scripting language) to script a Flash movie—for example, by calling SetVariable or GetVariable. Flash Player only permits this operation when the HTML page is from the same domain as the Flash movie it attempts to script.

Applying the rules

Flash Player 7 requires that movies must come from exactly the same domain to be able to script one another. In addition, movies that are served over nonsecure protocols, such as HTTP, cannot script movies that are served over HTTPS (the reverse is not true: HTTPS movies may script HTTP movies). The same restrictions apply to HTML pages scripting Flash movies.

These new rules apply only when one or both of the movies are made for Flash Player 7. If both movies are made for Flash Player 6 or earlier, Flash Player 7 uses the old rules. Note that the old rules permit movies from the same superdomain to script each other; they also permit HTTP movies to script HTTPS movies.

When two movies are from different domains, Flash Player ensures that the two movies have different copies of the ActionScript global object. The global object is usually implicitly referenced. For example, all objects in the Flash Player standard library, such as MovieClip, Array, and so forth, are part of the global object. The global object also holds global variables created by assigning properties to _global. Separating global objects between movies from different domains has occurred since Flash Player 6. However, Flash Player 7 introduces a new restriction: movies made for Flash Player 6 or earlier can never share a global object with movies made for Flash Player 7 or later, even when the movies are from the same exact domain and protocol. This may have subtle repercussions for sites that mix movies made for Flash Player 6 and 7.

Granting cross-movie scripting permissions

If you have movies that you will serve from different domains and you want the movies to be able to script each other, you can grant cross-domain scripting permission. You do this by using the ActionScript method System.security.allowDomain, which has existed since Flash Player 6 but takes on slightly different behavior in Flash Player 7.

If you have a movie at http://www.mysite.com/controller.swf that needs to load another movie from http://utility.flashutils.com/helper.swf and call methods defined in helper.swf, Flash Player 7 allows the process as long as you put the following ActionScript in helper.swf:

Ensure that you understand the consequences of calling System.security.allowDomain. The above ActionScript permits any movie from the www.mysite.com domain to script any movie from the utility.flashutils.com domain.

When a movie made for Flash Player 6 calls System.security.allowDomain and another movie made for Flash Player 6 or earlier performs cross-movie scripting on that movie, System.security.allowDomain works with superdomains. For example, with the above ActionScript, any movie from www.mysite.com, store.mysite.com, and so forth can cross-script any movie from utility.flashutils.com, www.flashutils.com, and so forth. When either the movie calling System.security.allowDomain or the movie performing cross-movie scripting is made for Flash Player 7 or later, System.security.allowDomain interprets domains exactly. This means that the above ActionScript would only permit movies from www.mysite.com to access movies from utility.flashutils.com.

When a movie made for Flash Player 6 calls System.security.allowDomain, this permits non-HTTPS Flash movies of any version from the permitted domain to access HTTPS movies in the domain of the granting movie. For example, the above ActionScript would permit any Flash 7 movie from www.mysite.com to script HTTPS movies in the utility.flashutils.com domain.

In contrast, when a movie made for Flash Player 7 or later calls System.security.allowDomain, this does not permit cross-scripting of HTTPS movies by non-HTTPS movies. To grant permission for movies made in version 7 or later, you must call the new System.security.allowInsecureDomain method. If you have a movie at http://www.mysite.com/controller.swf that needs to load another movie from https://secure.mysite.com/creditcard.swf and call methods in creditcard.swf, Flash Player 7 will permit the operation as long as you put the following in ActionScript in creditcard.swf:

We do not recommend this practice, because allowing non-HTTPS documents to access HTTPS documents can compromise the security offered by HTTPS. It is preferable to serve over HTTPS all Flash movies that require scripting access to HTTPS movies. However, if using HTTPS for all your movies is prohibitively expensive or impractical, System.security.allowInsecureDomain will override the Flash Player default HTTPS protection.

A LocalConnection object allows two Flash movies to communicate with each other, even when they are not located in the same instance of Flash Player—for example, when the two movies are in separate browser windows. LocalConnection objects have been available since Flash Player 6.

A movie calls LocalConnection.send to initiate a remote procedure call over a LocalConnection. When a movie calls LocalConnection.send and there is a receiver for the specified channel, Flash Player checks whether the domain of the sender matches the domain of the receiver. If so, the call proceeds.

A movie may also call LocalConnection.domain to determine its own domain.

Applying the rules

Flash Player 7 requires that a LocalConnection sender must come from exactly the same domain as the receiver. In addition, movies that are served over nonsecure protocols, such as HTTP, may not make LocalConnection calls to movies that are served over HTTPS (conversely, HTTPS movies may make LocalConnection calls to HTTP movies).

These new rules apply only when any of the movies is made for Flash Player 7 or later. If both movies are made for Flash Player 6, Flash Player uses the old rules, even in Flash Player 7. The older rules permit a movie to make a LocalConnection call to any movie from the same superdomain and permit HTTP movies to make LocalConnection calls to HTTPS movies.

In Flash Player 7, when a movie made for Flash Player 6 calls LocalConnection.domain, the return value is the movie's superdomain. When a movie made for Flash Player 7 or later calls LocalConnection.domain, the return value is the movie's exact domain.

Note that there is one aspect of LocalConnections that continues to use superdomains, even for movies made for Flash Player 7 and later: the domain in a channel name. A channel name is simply the name that a listener connects with and that a sender uses to identify a listener to send to. When a Flash movie calls LocalConnection.connect with a channel name that begins with an underscore, Flash Player uses the channel name exactly as provided, without regard to domain. However, for channel names that do not begin with an underscore, there is an implicit domain name added to the beginning of the channel name. For example, when a listener from www.mysite.com calls the following:

The channel name becomes mysite.com:myChannel. If a sender from www.mysite.com or store.mysite.com calls:

Flash Player sends the call to the channel, mysite.com:myChannel, which corresponds to the listener's connect() call above. The only time when a movie must add a domain name to a channel name is when it sends to a listener outside its own superdomain. In that case, the sender must explicitly specify the domain and channel name. If a sender from www.anothersite.com were to send to the listener above, here is the syntax you would use:

In this situation, be aware that you should use the listener's superdomain, not the listener's exact domain.

Granting LocalConnection permissions

If you have movies that you will serve from different domains, and you want those movies to be able to make LocalConnection calls to each other, grant cross-domain LocalConnection permissions. Do this by implementing an event handler called allowDomain on your LocalConnection listener. The LocalConnection.allowDomain handler has existed since Flash Player 6 but it behaves slightly differently in Flash Player 7.

Say you have a movie at http://www.mysite.com/controller.swf that must make a LocalConnection call to another movie loaded from http://utility.flashutils.com/helper.swf. You would use the following ActionScript in helper.swf:

Note that the domain expected by that code is the exact domain of the caller, www.mysite.com. It is typical for the allowDomain handler to work this way in Flash Player 7. However, this is different from the way the allowDomain handler worked in Flash Player 6. At that time, it used superdomains. To preserve backward compatibility in Flash Player 7, if the LocalConnection caller and the LocalConnection listener are both version 6, the argument for LocalConnection.allowDomain is the caller's superdomain:

When a LocalConnection listener appears in a movie made for Flash Player 6, Flash Player uses its allowDomain handler for all LocalConnection calls, even when the listener is in an HTTPS movie and the caller is not. However, when a listener appears in an HTTPS movie made for Flash Player 7 or later, and a caller makes a LocalConnection call in a non-HTTPS movie, the listener must implement a new handler called LocalConnection.allowInsecureDomain or else Flash Player will not permit the call. This is similar to adding System.security.allowInsecureDomain in Flash Player 7 (see the section Granting Cross-Movie Scripting Permissions earlier).

Here is an example:

We do not recommend implementing LocalConnection.allowInsecureDomain because allowing non-HTTPS documents to access HTTPS documents can compromise the security offered by HTTPS. It is preferable that you serve over HTTPS all Flash movies that make LocalConnection calls to HTTPS movies. However, if using HTTPS for all your movies is prohibitively expensive or impractical, LocalConnection.allowInsecureDomain will override the Flash Player default HTTPS protection.

The SharedObject class allows Flash movies to create persistent, cookie-like data on a user's machine. You perform this operation by calling SharedObject.getLocal. This operation stores persistent shared objects to—and later retrieves them from —a location that depends on the domain of the movie that calls getLocal, as well as (optionally) part or all of the movie's URL.

Movies connecting to Flash Communication Server MX can also create locally persistent shared objects by calling SharedObject.getRemote. The changes described here for getLocal also apply to locally persistent shared objects created with getRemote.

Every domain has a shared object quota. This is an allocation of the user's disk space in which movies from that domain may store persistent shared objects. Users can change the quota for a domain at any time by choosing Settings from the Flash Player context menu. When a movie tries to store a persistent shared object that causes Flash Player to exceed its domain's quota, a dialog box appears, asking the user whether to increase the domain quota.

Flash movies connecting to Flash Communication Server can send audio and video streams from users' microphones and cameras by calling Microphone.get and Camera.get. When a movie does so, Flash Player displays a privacy dialog box that asks the user whether a movie can use their microphone or camera. When users reply, they can make their answer permanent. When that happens, Flash Player records their decisions on a per-domain basis. For example, if a movie from www.mysite.com asks to use the user's camera or microphone and the user specifies a permanent Yes for that domain, then any movie from www.mysite.com can call Microphone.get or Camera.get afterwards with any movie requests without displaying the privacy dialog box.

SharedObject, Microphone, and Camera functionality has existed since Flash Player 6.

Applying the rules

In Flash Player 6, the domains that Flash Player chooses for shared object storage, shared object quotas, and privacy settings are superdomains. For example, for a movie from www.mysite.com, Flash Player 6 would use the superdomain mysite.com.

Flash Player 7 chooses domains based on the version of the movie that's playing. For movies made for Flash Player 6, Flash Player 7 continues to use superdomains by default. For movies made for Flash Player 7 or later, Flash Player 7 uses the exact domain of the movie by default. For example, for a Flash Player 7 movie from www.mysite.com, Flash Player 7 would use the exact domain www.mysite.com.

Choosing which rules to use

You can override the defaults (superdomains for Flash Player 6 movies and exact domains for movies made for Flash Player 7 or later) by setting a new global variable called System.exactSettings. When you set this variable to true, Flash Player 7 uses exact domains; when you set it to false, Flash Player 7 uses superdomains.

Normally, these defaults should be reasonable but there are two major scenarios where you might want to change the value of System.exactSettings from its default value:

• If you have a movie made for Flash Player 6 that has created persistent shared objects and you want to upgrade it to a Flash Player 7 movie and you want to be able to retrieve the shared object data created by the version 6 movie, then you should set System.exactSettings = false in the Flash Player 7 movie. This forces Flash Player to read persistent shared objects from the movie's superdomain. This is desirable because it stored them there when the Flash Player 6 movie created them.
• If you have multiple cooperating movies, some made for Flash Player 6 and some for Flash Player 7 (or later). If these movies need to share the data in a persistent shared object, you must ensure that they all have the same value for System.exactSettings so that Flash Player uses the same domain for all of them.

If you change the value of System.exactSettings from its default, do so very early in your movie, preferably at the beginning of Frame 1. Flash Player will not allow you to change the value of System.exactSettings after it has used it once in a decision about shared objects or privacy settings.

It is never possible to read or write persistent shared objects from another domain. If you need to access data in another domain's persistent shared objects, create another movie that you serve from that domain and transfer the data using ActionScript, which will probably involve calling System.security.allowDomain (described earlier in the section Granting Cross-Movie Scripting Permissions).

Debugging Security Problems

As we mentioned earlier in the section Security Restrictions for Data Loading, you can diagnose data-loading problems caused by differences between Flash Player 6 and Flash Player 7 using the mm.cfg and flashlog.txt files. However, you can debug security in your movies more comprehensively by publishing your movies with debugging enabled. Play your movies from their production URLs using the Debug version of a browser player (ActiveX control or plug-in) and connect to the Flash authoring application when playback begins. When movies play while connected to the Flash Debugger, warning messages appear in the Output panel if a security check fails. These warning messages report the URLs involved in the security check, which help you determine security-related problems so you can fix them.

Flash Player 7 continues to improve on the Flash Player tradition of stability, performance, and security. With the changes described in this article—exact domain matching and HTTPS protection—Flash Player 7 fulfills the Internet community's expectations for client-side security better than before.

The introduction of policy files also makes Flash Player's security model more flexible to the needs of Flash developers. Previously, it was impossible to load non-SWF data from other domains. Now Flash developers can do so easily. This new permission mechanism opens the way to a whole new class of Rich Internet Application, including applications that can access web services directly from the client.

To remain up to date about Flash security, please read the latest security documents in the Flash Player Develper Center.