How secure is NativeScript? | The NativeScript Blog

Watch the webinar "Best Practices for Securing Your Mobile Apps" to get some tips and tricks on NativeScript security!

One of the questions we receive from the community is how secure is NativeScript as a framework compared to the native iOS and Android frameworks. Very often there is not enough knowledge how the native frameworks protect the applications and how the use of JavaScript affects the “security” of the apps.

So let's fix this! I will give you an overview of how the native apps protect the code and data and how NativeScript does this.

Mobile security is a very broad topic, so I will not go into details here. I will try to explain how NativeScript reuses the work already done in the native platforms. If you are interested in learning more about mobile security I can advise you to start with these whitepapers first:

What we are doing in NativeScript is use the already implemented best practices in iOS and Android for protecting the data and the code.

It is really about this - protecting the application code and protecting the data that your applications uses and stores on the device. Let's start with the data part.

Protecting the Data

Companies and developers are often concerned to protect sensitive data. The rule of thumb here of course is not to store any data that is sensitive on the device.

In NativeScript we use entirely the native APIs to

get the data,
store the data on the device

This means that we use the underlying native connection API to get the data from your server. As in the native application,s you are able to use HTTPS/SSL endpoints. You are also able to use Wi-Fi and VPN.

iOS and Android provide a set of cryptographic APIs for use by applications. These APIs include implementations of standard and commonly used cryptographic primitives, such as Advanced Encryption Standard (AES), Rivest-Shamir-Adleman (RSA), Digital Signature Algorithm (DSA), and Secure Hash Algorithm (SHA). Additionally, APIs are provided for higher-level protocols, such as Secure Socket Layer (SSL) and HTTPS. To read more please follow these links - iOS KeyChain and Android KeyStore.

To store simple key/value data on the device you have access to the entire API available in the native frameworks. The SecureStorage plugin in NativeScript gives you a cross-platform way of using those APIs.

For larger data sets that are not simple key:value pairs, you will need a data storage that is queryable. For this case a very popular solution is the SQLCipher database. SQLCipher is an SQLite extension that provides transparent 256-bit AES encryption of database files. Pages are encrypted before being written to disk and are decrypted when read back. Due to the small footprint and great performance it’s ideal for protecting embedded application databases and is well suited for mobile development.

As you can see there is no difference between NativeScript and the native application frameworks in securing the data on the device. Your data in NativeScript is as protected as in a native application because you can use the same mechanisms and libraries to protect it.

Now let’s see what are the options you have to protect the code of the application.

Protecting the Code

In a recent survey, about 80% of the NativeScript developers shared that they want to protect their code.

It is straightforward to download a published application package from the public iOS and Android marketplaces. In this case, anyone can open the app package and inspect all the assets there - code, images, anything that is part of the package. It is very similar to a published website where the source code on the client side is available for everyone to see.

This is true for native iOS and Android applications. Once the app package is downloaded the source code of the application can be seen. I will not go into details how the source code of the app can be seen, but there are enough free tools that can reverse engineer and display the code. The process is different for iOS and for Android, due to the huge difference in the way Java and Objective-C code is being compiled.

Now the thing to make very clear here is that there is no 100% guaranteed solution that will protect the code you are shipping. If it executes, it can be decompiled.

In consideration of the above, code protection, is all about setting the as high a barrier for reverse engineering by adding additional layers of security on top of the plain source code. These tools and layers are added when the application is built in Release mode.

In Android it is very easy to read the app code. Java applications are compiled to bytecode that runs on a virtual machine (JVM). Everyone that downloads the APK can read the code inside by using a dedicated decompiler.

In iOS it is harder to read the code, the process is a little bit more complex, but again not impossible.

In Android the additional layer of security is provided by a tool called ProGuard. ProGuard is part of Android Studio and can obfuscate the Java code you are using so that it is harder to reverse engineer while, again, still not impossible.

In NativeScript we are using JavaScript as an application language. Since JavaScript is an interpreted language it does not compile during the build process and the files are available as part of the application package.

As a rule of thumb you should not download code from the server and execute it, as this can easily become a security hole.

What can you do in NativeScript to protect the code?

Obfuscation

You have several options - very similar to what a native developer would do. You can use an obfuscation tool - like UglifyJS or similar to obfuscate the code when you build in release mode. This will make the code protection on par with what you achieve with the ProGuard tool for Android. The obfuscation tools not only make the code unreadable but some of them also remove unneeded code and mangle it to make it smaller. Combined this with WebPack and you can actually optimize the size and the loading time of your NativeScript application.

The above scenario is most commonly used in web pages for protecting and optimizing the code running on the web.

If you implement the above technique you will achieve the same level of protection found on the web and in Android native apps.

Code Encryption

The next level of protection that we can enable in NativeScript is code encryption. We already saw that there are native solutions for data encryption which you can use today.

For code encryption this is additional level of protection that can operate over obfuscated or over plain code. There are various techniques that we can implement here and to provide a more robust solution for code protection. Again remember - not unbreakable, but just an additional layer of protection that will make stealing your code harder.

We already have a POC solution for code encryption and in the next blog post I will go and deep dive what we have in experimental state. We are looking for community input so we can make this feature complete. If you are interested in playing with the POC of the encryption plugin today, please email me ([email protected])

For full transparency, we will publish the source code, thus allowing the broader community to uncover any flaws and contribute to making NativeScript a more secure mobile platform.

Protection against unauthorized app package or code modifications

As an additional protection in NativeScript, logic can be added to your applications to prevent your mobile application from executing, if the framework detects part of your application has been compromised or modified by an attacker.. Imagine an attacker downloads your app packages and inserts code that bypasses authentication or any other logic. If this happened, the attacker could run the modified application on a rooted device to find/download sensitive personal or company data.

We are looking to implement an unauthorized application modification feature in NativeScript. So we can get the best implementation, we would like to solicit your feedback.

Remember - no protection is unbreakable. It is good practice to secure sensitive code on the server, not downloaded to the client side or a publicly available package like a mobile application. This advice is the right practice for native apps and also for NativeScript apps.

MatrixImage

We are pretty much open for any comments on this. Please write your feedback below. If you prefer a private chat, let’s do it.