The Flash Player sandbox bridge

One challenge that many Flash developers face is how to exchange information between SWF applications from different domains. Developers need a solution that is both secure and works with the architectural design of their application. With the Flash Player 11.4 release, we added one more option for developers by porting the AIR sandbox bridge APIs to Flash Player. This feature will help developers who are currently using Security.allowDomain("*") to have more granular control over what data they share with parent or child SWF applications.

For background, the sandbox bridge was originally designed for AIR applications. We knew that there would be valid use cases where a trusted AIR application would need to selectively exchange information with untrusted content loaded from the web. It was critical that AIR developers could easily control the information that was made available to untrusted content while still protecting their sensitive data. The sandbox bridge was designed to solve this need.

The sandbox bridge concept is supported by two properties on the LoaderInfo class. When the parent application wants to expose a function or property to the child application, the parent can add it to the LoaderInfo.parentSandboxBridge. When the child application wants to expose a function or property with the parent application, then the child can add it to the LoaderInfo.childSandboxBridge. All data is serialized and then passed by value. Code examples for these APIs can be found here.

For Flash Player developers, this may be a better option than using Security.allowDomain("*"). With the allowDomain(*) approach, every aspect of your SWF application is made available to whomever loads your application. The sandbox bridge allows the developer to be more specific about what is shared across domains. For some time, Flash Player has also provided the LoaderInfo.sharedEvents property as a way to selectively share information across domains. The drawback with the sharedEvents approach is that it requires applications to be designed around an event-driven model. With the sandbox bridge, the data is made available immediately and can be accessed directly.

Developers should be aware that the sandbox bridge will not allow you to control which domains can access the data or function. If a malicious parent SWF loads your SWF as a child, then it will be able to see anything that you have exposed on your childSandboxBridge. Therefore, you should only share data or functions over the bridge that has no value to potentially malicious hackers. In most cases, a well designed sandbox bridge approach will have less risk than the all-or-nothing approach of using Security.allowDomain("*").

Adobe is continuing to work on addtional APIs that will help developers create secure SWF applications.  This new API is just one small step that we are taking to enable developers to continue to create great content for the Web.

To learn more about Flash Player security, visit the security page on the Flash Player Developer Center.