Does allow list requires importing cordova.js to work correctly?

[ooo2003003v2]

Hello there, I'm trying to set an allow list/whitelist for a few sites. However my website is hosting in a cloud server. I wonder if I need to import cordova.js into my project for the allow list/whitelist to work correctly?
Another question is that I saw that the _system target"window.open(url, '_system')" only mentioned in the cordova-plugin-inappbrowser. Does hyperlink with target _system only works if I add the cordova-plugin-inappbrowser to my project?

[breautek]

I wonder if I need to import cordova.js into my project for the allow list/whitelist to work correctly?

I don't believe so because the allow list plugin does not have a JS interface and is something that I believe is loaded on load, rather than initialised in the JS runtime. Any plugins that offer a JS API does need cordova.js since it is also responsible for loading in the plugin JS modules as well as providing the native bridge to make native API calls.

But loading your web app remotely is also not a supported configuration and is not something really tested for. The web app should be bundled with the binary.

Another question is that I saw that the _system target"window.open(url, '_system')" only mentioned in the cordova-plugin-inappbrowser.

_system is a in-app browser plugin specific concept. If the plugin is not installed (also means you need the binary bundled cordova.js), then you'll be using the browser-native window.open which does not have a _system keyword, and thus will treat _system has a context name instead.

Also note that by default the in app browser plugin doesn't clobber window.open. You'd need to explicitly clobber (if you desire to force all window.open calls to use the plugin by reassigning it to the plugin method. See https://github.com/apache/cordova-plugin-inappbrowser?tab=readme-ov-file#windowopen

To re-iterate, If you're loading your web app remotely, then using cordova.js to use native device APIs can be considered breaking user agreements and can also be considered a RCE (Remote Code Execution) vulnerability. This vulnerability may exists even if you're remotely hosted code does not make use of cordova.js but cordova.js is still available to be loaded into your web app environment.

So if you plan to use Cordova to provide a remote hosted application that uses standard browser features, then consider Progressive Web App deployment instead. It will be far more secure.

If you're using Cordova because you need access to native device APIs, then you should architect your application to be able to run offline locally on device.

[ooo2003003v2]

I wonder if I need to import cordova.js into my project for the allow list/whitelist to work correctly?

I don't believe so because the allow list plugin does not have a JS interface and is something that I believe is loaded on load, rather than initialised in the JS runtime. Any plugins that offer a JS API does need cordova.js since it is also responsible for loading in the plugin JS modules as well as providing the native bridge to make native API calls.

But loading your web app remotely is also not a supported configuration and is not something really tested for. The web app should be bundled with the binary.

Another question is that I saw that the _system target"window.open(url, '_system')" only mentioned in the cordova-plugin-inappbrowser.

_system is a in-app browser plugin specific concept. If the plugin is not installed (also means you need the binary bundled cordova.js), then you'll be using the browser-native window.open which does not have a _system keyword, and thus will treat _system has a context name instead.

Also note that by default the in app browser plugin doesn't clobber window.open. You'd need to explicitly clobber (if you desire to force all window.open calls to use the plugin by reassigning it to the plugin method. See https://github.com/apache/cordova-plugin-inappbrowser?tab=readme-ov-file#windowopen

To re-iterate, If you're loading your web app remotely, then using cordova.js to use native device APIs can be considered breaking user agreements and can also be considered a RCE (Remote Code Execution) vulnerability. This vulnerability may exists even if you're remotely hosted code does not make use of cordova.js but cordova.js is still available to be loaded into your web app environment.

So if you plan to use Cordova to provide a remote hosted application that uses standard browser features, then consider Progressive Web App deployment instead. It will be far more secure.

If you're using Cordova because you need access to native device APIs, then you should architect your application to be able to run offline locally on device.

I see. Thx for anwsering my questions. I'm still a bit confused, so it's incorrect that setting the content prop in the xml config to an extenal site? And, in theory, if I move all the plu-in js files and cordova.js to the extenal site folder, will the allow list should works properly? Or the list only works if the site stores inside the www folder?

[breautek]

I'm still a bit confused, so it's incorrect that setting the content prop in the xml config to an extenal site?

Yes. Setting content to an external site will work to a degree but Cordova isn't designed to operate this way, and the Google Play store / iOS App Store has policies in place regarding how remote web content should interact with native device APIs which you will most certainly break if you intend to deploy through those distribution channels.

Just speaking about web apps in general, Google & Apple allows remote web content loaded in their webviews, but they should not access native device APIs.

On a more functional note, Cordova offers a development tool to serve the platform web content over a webserver, which you can set the content src appropriately to make use of this development tool. This allows you to update the www assets without repacking/rebuilding the binary for faster development iterations. So there are valid reasons why you'd point content to a remote server, but for production release the content should be pointing to locally bundled assets.

And, in theory, if I move all the plu-in js files and cordova.js to the extenal site folder, will the allow list should works properly? Or the list only works if the site stores inside the www folder?

In theory yes, if you copy the platform www assets and load them with your external site, it probably will work technically. But you're also opening yourself to RCE and breaking the aforementioned app store agreements. And the platform www assets are platform-specific, so you also won't be able to support multiple platforms (e.g. iOS and Android).

Even if your site is completely secure and does nothing malicious itself, the fact that the mobile application loads content remotely opens the possibility for MITM (Man-in-the-Middle) attacks, where if your app is launched in a malicious network, yourserver.com might not be actually yourserver.com and point to a malicious host instead, and then use native device APIs installed/exposed by your app can be used to pull information on your user for malicious intent.

So I cannot stress enough that the web application should be bundled with the native binary. The native binary should not download anything that can be remotely executed. It's fine for the native binary to download supporting assets like data files, images, etc, but not code.