Understanding the Flash Security Sandbox One Step at a Time

The Flash security sandbox is a nice little entity that wraps any flash application in an attempt to prevent malicious activity. Most of the security involves cross-domain interaction. In essence it prevents a SWF from one domain loading in a SWF from another domain and editing information or the process of information which might have otherwise been secure. In the flash world I do believe that this sandbox is necessary but it does cause a lot of problems and thus headaches.

When a SWF loads, it places all of its classes into the Flash Player’s memory. If it loads another SWF then it checks to see if that SWF has any of the classes already loaded into memory and uses that instance of the class rather than loading a second instance. One of the projects we work on involves a centralized framework SWF which is essentially our API. This framework SWF loads in different SWFs on other domains which share the same code base. The idea was that we could update the framework SWF and the changes would get propagated out to every different domain. Unfortunately when you add cross-domain into the mix this is when you start to run into problems. When the child SWF gets loaded in it also loads its own version of the classes into memory. Looking through the security documentation I didn’t see any way around this. Adobe should make a property that can allow you to overwrite other classes if you load in a SWF from another domain. I imagine it could work like the Security.allowDomain().