Securing Ionic Or Cordova Applications At The Frontend

As we all know, Security is a difficult and very vast topic. With every new technology come new threats.  Therefore, there is always a possibility of malicious attacks and 100% security of your application is never possible. That doesn't mean that your development efforts go waste, there are challenges though,  but it's our responsibility to ensure the security of our application from our side at least. 

Most developers forget that an Ionic or Cordova applications are just like any other web application, which also includes main file, i.e index.html that includes HTML, JavaScript, and CSS code. From the security point of view, there is almost no difference between a normal web application running on the web and Cordova application running on a device, which means that the source code of your mobile application can be easily inspected by any user who downloads it and any content placed within your Ionic/Cordova application is easily readable by others. 

It is therefore important that we must at least use some basic approaches to secure our Ionic/Cordova applications and the data it holds or transmits to minimize the possibility of code tampering or malicious attacks, especially when it comes to private user data.

Now let's look at certain ways at the front end side, by which we can significantly lesson malicious attacks, harden our applications and also hopefully minimize the code tampering as we can never eliminate this completely.
 
1. Content Security Policy (CSP) Management
The truly determined attackers will do everything in order to tamper the code if any vulnerability with the code is discovered. Let's say, you are using a third party API call or JavaScript library, then they might find ways to exploit this so that their malicious code runs within the application instead.

To prevent such attacks by defining which network requests are allowed to be made and by identifying if the resource is loaded from the trusted source.

Cross-site scripting (XSS) attacks, for example, bypass the same origin policy by tricking a site and delivering malicious code along with the intended content. This is a problem as browsers trust all of the code on a page as a legitim part of that page's security origin. If an attacker gets successful in injecting any code, there is almost no way to get out of this and the secret information is exfiltrated to the wrong community. So. we'd obviously need to prevent that.

The issue is that the browser is not capable to distinguish between the script that is the part of the application and script that contains malicious code and is being injected by a third-party (attacker). So, CSP defines the CSP HTTP header, which allows us to create a whitelist of sources that delivers trusted content, and it tells the browser to execute or render only the resources from those sources instead of blindly trusting everything that a server delivers. If an attacker still finds a hole through which he can inject the script, the script will not match the whitelist and therefore will not be executed.

This CSP meta-tag is placed in the main file, i.e. index.html within your application.
This looks like following:
<meta HTTP-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com ">
script-src is a directive that has control over the set of script-related privileges for a particular page. Her we have 'self' as one valid source of script and https://apis.google.com  as another. Hence, the browser downloads and executes the script from the current page's origin as well as from apis.google.com over HTTPS.
With this CSP defined, the browser will not allow the script to load from any other source and simply throws as an error. 
When you define your CSP for the application, you have to be careful as it might block certain resources that your project requires - so you should be aware of the sources you need in order to run your project successfully.
For more details about CSP, you can check following sites:
http://masteringionic.com/blog/2018-01-09-securing-ioniccordova-mobile-applications/
https://content-security-policy.com/

 
2. Whitelisting
You must have already noticed that Ionic applications for iOS or Android also use Cordova which provides Network Whitelist Plugin for providing cross-site scripting protection for reviews that don't support CSP. With the help of this plugin, you can implement the following access controls within the applications in config.xml file:
Navigation, which defines the URLs, the webview can navigate to. By default, file:// navigations are allowed.
 Intents define the application access to the system communication protocols.
Network requests define which requests are allowed to be made, i.e XHR, images etc.
 
3. JSON Web Tokens (JWT)
There is always a security concern with transmitting data between parties. Firstly, you aren't sure if the senders really are who they say they are and secondly, has the data been tampered with en-route? 
JWT is one approach to solve this and be sure if the sender is really who they say they are and to check if the data has tampered.

JSON Web Token (JWT) is an open standard that defines how information can be securely shared between parties in digitally signed and compact JSON format. As JWTs are small in size, they can be quickly transmitted through a POST parameter, inside HTTP header or via URL.

A JWT consists of following three parts, which are separated by dots ( . ) :
The header is the first part of the JWT, which is divided into two types, the type of the token, i.e JWT and the hashing algorithm (RSA, HMAC or SHA256).
The payload is the second part of the JWT and contains the claims, which are statements about the user and additional metadata.
Signature is the final part of the JWT which helps in the verification of the sender of the JWT and to make sure if the message didn't tamper during the transmission.
JWTs can be signed digitally and this makes them ideal for transmitting the data securely between parties. The digital signature is calculated using the Header and Payload of the JWT itself, so the client is able to trust that the sender is who they say they are and the data hasn't been tampered by an unknown party.