This post was originally published at Security Risks Associated with Native Packagers

imageNative packaging solutions have enabled organizations to leverage web technology and develop cross-platform applications for smart mobile devices. However, these solutions continue to have a persistent drawback: all app resources are packaged unencrypted. It is very easy to copy the binary executable for a packaged app, unzip the binary and retrieve sensitive resources, including the source code. Local application data is also stored unencrypted by default.

Over the past several years, it seems like we haven’t gone more than a few weeks without hearing about a major security breach on the evening news. While not every security flaw involves the same weakness, native packaging solutions potentially put proprietary source code and sensitive data at risk of unauthorized disclosure. Check out this video to see just how easy it is to recover app resources from a packaged binary.

Application development has evolved in recent years. Gone are the days when applications were primarily server-side entities with a lightweight client-side component. Many of today’s apps are comprised of a rich client-side interface containing the UI specification, application and business logic, occasionally calling into a fabric of cloud-based APIs for backend integration. This programming model allows computational load to be shifted from the server to the client for more interactive and performant applications.

However, it also means that more of the app’s code and data live on the client side. For hybrid app developers, this shift is problematic. Developing an engaging application requires a significant investment of resources and time to design, code, test, and maintain the app over time. By using a native packager, developers put their investment at risk of theft, reverse engineering, and exposure to competitors.

Although countermeasures such as code minification and obfuscation can make it more difficult for a potential adversary to make sense of the extracted source code, it is still human readable, putting your code at risk.

Similarly, native packagers do nothing out of the box to protect any locally stored data. Developers would need to develop a data encryption plugin to protect the confidentiality of any local data. This sort of extra development effort delays the completion of the project and imposes additional expense over the lifetime of the app to maintain this security componentry across different device platforms.

With Sencha Space, developers will still have all the benefits of building their apps using web technology without the risk of exposing their source code to anyone who cares to see it.

Until now, developers had to just accept these drawbacks as a tradeoff for the conveniences native packagers provide. However, Sencha Space provides an alternative solution: a managed web application environment that provides integrated local data encryption for all application resources, including source code. With Sencha Space, developers will still have all the benefits of building their apps using web technology without the risk of exposing their source code to anyone who cares to see it. Because Sencha Space provides both an encrypted file system and encrypted SQL database, developers can focus their energy developing innovative applications, not reinventing the wheel on security or worrying about their plaintext source code exposed for anyone to see.

To learn more about Sencha Space, go to http://www.sencha.com/space

You can also subscribe to Space for free at: https://manage.space.sencha.com

Build better apps for more devices at lower cost. Learn how at Senchacon 2015. Register today.

.right, .alignright float: right; margin: 0 0 10px 10px;
.left, .alignleft float: left; margin: 0 10px 10px 0;

Continue reading here:

This post was originally published at Security Risks Associated with Native Packagers