Cordova Plugin Whitelist

In Cordova version 4.0 or higher, you can implement a whitelist policy to navigate your application WebView using this specific plugin. Before we go further, let us discuss about the domain whitelist. The plugin whitelist can be defined as the security model that is responsible for controlling an access to the external domains. The Cordova mainly offers a configurable security policy that defines which of the external sites can be accessed. If we want to know about the compatibility of the plugin, it is supported in Android 4.0.0 or above.

Installation:

To add this plugin in your app, you must require to install it. You can install the plugin from Cordova CLI or npm. For doing this, you need to type the below command:

$ cordova plugin add cordova-plugin-whitelist
$ cordova prepare

Navigation Whitelist

The main task of the navigation whitelist is to control which URLs the WebView itself can be navigated to. It should be noted that the specific plugin is applicable only for top-level navigations. Also note that file:// URLs is the only allowed default navigations. You must need to add <allow-navigation> tags to the config.xml file of an app to allow the other URLs,:

Example:

<!?below command allows javatpoint.com link-->
<allow-navigation href="http://javatpoint.com/*" />
<!-- The below command is used for allowing the wildcards for the protocol as a suffix to path, or prefix to the host, -->
<allow-navigation href="*://*.javatpoint.com/*" />
<!?below command uses the wildcard for whitelist the entire network over HTTP and HTTPS.
*NOT RECOMMENDED* -->
<allow-navigation href="*" />
<!? three declarations that mainly equivalent to above code-->
<allow-navigation href="http://*/*" />
<allow-navigation href="https://*/*" />
<allow-navigation href="data:*" />

Intent Whitelist

This whitelist is responsible for controlling those URLs which an app allows to ask to open. For doing this, we need to add the <allow-intent> tags in config.xml. The below code demonstrates how it will be done:

<!--  below command allows the links to web pages -->
<allow-intent href="http://*/*" />
<allow-intent href="https://*/*" />
<!--  It allow links to javatpoint.com for opening in a browser -->
<allow-intent href="http://javatpoint.com/*" />
<!-- The below command is used for allowing the wildcards as a suffix to path, or prefix to the host, -->
<allow-intent href="*://*.example.com/*" />
<!?below command can allow SMS links, by which messaging app can open-->
<allow-intent href="sms:*" />
<!--  below command can allow tel: links, by which dialer can open-->
<allow-intent href="tel:*" />
<!--  below command can allow geo: links, by which map can open-->
<allow-intent href="geo:*" />
<!--  below command allow all unrecognized URLs, by which installed apps can open 
*NOT RECOMMENDED* -->
<allow-intent href="*" />

In case, if the <allow-intent> tags are not used then it means that the external URLs requests will not allow. By default, the liberal set of allow-intent entries are included in the default Cordova application. Based on the requirement of each app's, it is recommended to narrow this down.

If we talk about the Android platform, it is similar to send an intent of type BROWSEABLE.

Basically, this whitelist is not applied to the plugins. It is only for the hyperlinks and for the calls to window.open().

Network Request Whitelist

For controlling the network requests (images, XHRs, etc) that are allowed to be made via cordova native hooks, the Network Request Whitelist is used.

We recommend that you should use a Content Security Policy because it is more secure.

We need to add the <access> tags in the config.xml file. The below code shows how it will be done:

<!--  below command is used for allowing an images etc. to xyz.com -->
<access origin="http://xyz.com" />
<access origin="https://xyz.com" />
<!--  below command is used to access the subdomain maps.xyz.com -->
<access origin="http://maps.xyz.com" />
<!? below command is used to to access all the subdomains in xyz.com -->
<access origin="http://*.xyz.com" />
<!--  below command is used to enable the requests for the content: URLs -->
<access origin="content:///*" />
<!?Do not block any requests -->
<access origin="*" />

In the above code, we have used a set of <access> tags. If <access> tags are not used, then only request to file:// URLs are allowed. However, by default <access origin="*"> included by the default Cordova application.

Note: For reducing the redirect to the non-whitelisted websites, CSP rules should be followed for those webviews that supports CSP.

Content Security Policy

It is used to control the network requests such as images, XHRs, etc that are allowed to be made using the WebView directly.

If we talk about the Android and iOS platforms, the network request whitelist can not filter all types of requests such as <video> & WebSockets. You should use Content Security Policy <meta> tag with the whitelist for all the pages.

Example of CSP declarations:

<!?Default declaration:
    * gap: Mainly required by iOS platform (if use the UIWebView) and JS->native communication.
    * https://ssl.gstatic.com: Only for Android platform for TalkBack for its proper functions.
* Enable inline JS: It is responsible for adding the 'unsafe-inline' to default-src    
* Enable eval(): It is responsible for adding the 'unsafe-eval' to default-src
* It disables the use of inline scripts and eval(). You can changed it by:
   -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' data: gap: https://ssl.gstatic.com; style-src 'self' 'unsafe-inline'; media-src *">

<!?below command is responsible for allowing everything. It must be from same origin and foo.com -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' foo.com">
<!?The policy is used to allow everything except  
    * scripts: The scripts should be from the same origin and inline styles, and eval()
    * CSS: It should be noted that the CSS should be on same origin and inline styles.
-->
<meta http-equiv="Content-Security-Policy" content="default-src *; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'">
<!--  below command is used to allow XHRs only over HTTPS on the same domain. -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self' https:">

<!? below command is used to allow the iframe to https://javatpoint.com/ -->
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; frame-src 'self' https://cordova.apache.org">

For seeing the current security policy, see inside the head element in index.html file.

See the following code:

<meta http-equiv = "Content-Security-Policy" content = "default-src 
   'self' data: gap: https://ssl.gstatic.com 'unsafe-eval'; style-src 
   'self' 'unsafe-inline'; media-src *">

This is a default configuration. The below code is responsible for allowing everything from the same origin and example.com.

<meta http-equiv = "Content-Security-Policy" content = "default-src 'self' foo.com">

It is also possible to allow everything, but restrict CSS and JavaScript to the same origin. See the below code:

<meta http-equiv = "Content-Security-Policy" content = "default-src *; 
   style-src 'self' 'unsafe-inline'; script-src 'self' 
   'unsafe-inline' 'unsafe-eval'">

Changing Behaviour

If we talk about the variations in the behaviour of whitelist for various platforms, some of the variations can be noticed by platform or these whitelist features based on the concerns and capabilities of the underlying native technology.

The use of access and allow-navigation is supported by iOS As of 6.0.0 (Cordova iOS 4.0.0) plugin is not required because it is built into the iOS platform.
Androidplatform supports the use of access, allow-intent, allow-navigation. The Intents are the specific concept of Android.
Windows 10: If we talk about the Windows platform, the allow-navigation element like the Android and iOS platforms are supported by Windows. But a supported access element behaves a bit differently in the navigation. It is allowed to the specific URLs but for reducing the risk, Cordova and plugin APIs are disabled. CSP (Content Security Policy) rules are followed to control the image access rules, XHR, CSS in Windows 10.
Windows 8.0, 8.1, and Windows Phone 8.1: It does not support the navigation to the external URIs outside of the InAppBrowser The reason is because of the limitations of fundamental platform.
Windows Phone 8 (WP8): This platform does not support the allow-navigation or allow-intent, It uses the old definition of the access element.