The use of ENABLEDEBUGGER and ENABLEDEBUGGER2 enables support for remote debugging and also contains a poorly salted MD5 password hash. The tag does not offer any security guarantees and can be easily circumvented by using any hex editor tool. Not only is the remote debugging protection easily bypassed, the password the developer used to secure the file is easily recoverable. Flash uses a 16-bit salt added to the password and applies the MD5 hash algorithm to it. This is a weak salt and the password can be recovered using password cracking programs.

By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when changing the settings because an overly permissive cross-domain policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following excerpt is an example of using a wildcard to programmatically specify to which domains the application is allowed to communicate.

   flash.system.Security.allowDomain("*");

Using the * as the argument to allowDomain() indicates that the application's data is accessible to other SWF applications from any domain.

By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. Starting with Flash Player 9,0,124,0, Adobe also introduced the capability to define which custom headers Flash Player can send across domains. However, caution should be taken when defining these settings because an overly permissive custom headers policy, when applied together with the overly permissive cross-domain policy, will allow a malicious application to send headers of their choosing to the target application, potentially leading to a variety of attacks or causing errors in the execution of the application that does not know how to handle received headers.

Example 1: The following configuration shows the use of a wildcard to specify which headers Flash Player can send across domains.

  <cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="*"/>
  </cross-domain-policy>

Using the * as the value of the headers attribute indicates that any header will be sent across domains.

By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when deciding who can influence the settings because an overly permissive cross-domain policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay, and other attacks. Policy restrictions bypass vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is used to load or modify cross-domain policy settings.
Example 1: The following code uses the value of one of the parameters to the loaded SWF file as the URL to load the cross-domain policy file from.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

Example 2: The following code uses the value of one of the parameters to the loaded SWF file to define the list of trusted domains.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

As a convenient debugging option, certain Flex authoring tools allow developers to export Flex projects with the source code files for the project. The failure to disable this access for production files could severely compromise the security of the application. It will allow any end user to view the source of the Flex application by right clicking on the running SWF inside the browser and selecting view source. This results in a source disclosure vulnerability. It is recommended that this feature be turned off to avoid unintended access to the source code.

Source code often contains database usernames, passwords and connection strings and locations of sensitive files. It also reveals the detailed mechanics and design of the application's logic, which can be used to develop other attacks.

Starting with Flash Player 7, SWF applications loaded over HTTP are not allowed to access data of SWF applications loaded over HTTPS by default. Adobe Flash allows developers to alter this restriction either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when defining these settings because HTTP loaded SWF applications are subject to man-in-the-middle attacks, and thus should not be trusted.

Example: The following code calls allowInsecureDomain(), which turns off the restriction that prevents HTTP loaded SWF applications from accessing the data of HTTPS loaded SWF applications.

   flash.system.Security.allowInsecureDomain("*");

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.