Why is XSS Apache Cordova’s worst enemy?

12 April 2016
| |
Reading time: 4 minutes

While hybrid mobile application development is gaining in popularity due to its various advantages such as reusing existing web development skills, lower development costs, and smoother release process, new kinds of security risks have emerged. So I was curious to take a closer look about how the threat of cross-site scripting (XSS), a common web security vulnerability, evolves in the context of an Apache Cordova based application.

What is Apache Cordova?

Apache Cordova, less formally Cordova,  is an open-source mobile development framework that enables cross-platform development using widely adopted web technologies such as HTML5, CSS3 and JavaScript. Cordova wraps your web application into a native container that exposes internal services and resources such as the camera, contacts and file system, to name a few, through a JavaScript API. Additionally, Cordova comes with a plugin mechanism that allows you to easily extend your application with new functionalities through the official, third-party or custom plugins.

What’s under the hood?

Cordova’s native container wraps the native HTML rendering engine of each supported platform. For instance, on iOS it’s the UIWebView class which is wrapped and on Android it’s the WebView class. In other words Cordova wraps the native platforms browser that will execute the web application.

What’s wrong with the browsers?

As Douglas Crockford mentions in his Principles of Security talk you should never trust the browser since it cannot and will not protect your interests. One of the main reasons behind this statement is that browsers are nothing else than a remote code execution engine which downloads arbitrary code and then executes it on the fly. A dream target for any malicious user!

What is cross-site scripting (XSS)?

XSS can be classified as an injection attack since the browser’s rendering engines are the ones being tricked. Typically, an attacker manages to inject a malicious HTML/JavaScript payload into the system so that it eventually gets executed by the browser. Note that there are different flavours of XSS (reflected, stored and DOM) but it is beyond the scope of this blog article. For more informations I highly recommend you to read the following pages from the OWASP website:

What can you do with XSS?

Given that a XSS vulnerability exists in a web application, an attacker is potentially (exploitation likelihood heavily depends on the location/context of the vulnerability) able to execute arbitrary code into the victim’s browser context and perform malicious actions such as:

  • Deface the website (modify the DOM). For example, rendering a fake login form into the page in order to steal the legitimate user’s credentials
  • Steal, Modify or delete user’s data stored in the web storage (local/session)
  • Hijack the user sessions cookie/token

As you may notice, based on the examples listed above, that the consequence of such a vulnerability can be devastating depending on the nature of the website.

What can you do with XSS in Cordova based web application?

As already mentioned, Cordova exposes its native capabilities through a JavaScript API that is available in the global namespace of the web applications. That means that if a web application running within Cordova suffers from an XSS vulnerability, the attacker is able to invoke all exposed methods for malicious purposes. In other words, the attacker is able to access the native capabilities and resources of the device and could for example easily steal contact details, take pictures or locate the position of a user using the geolocation feature.

The good news is that since version 3 every feature from the core Cordova framework has been converted into a plugin that has to be added explicitly except for the Whitelist plugin which is added per default when a platform is added through the Cordova command-line interface (CLI) tool. For this reason it’s important to ensure that only plugins that your application really needs are added in order to reduce the attack surface.

It’s worth mentioning that there is a special flavour of XSS specific to mobile applications named cross-application scripting attacks (XAS). XAS attacks happen when another application installed on the device loads a URL containing a malicious payload into the Cordova WebView using inter-applications communication mechanisms provided by the operating system. For this reason it’s crucial that any “untrusted” data is carefully sanitized and output encoded.


Most mobiles phones nowadays contain sensitive private, company or customer data and are therefore an interesting target for cybercriminals. As we have seen an XSS vulnerability in a Cordova application is a serious business since it opens the doors to the internal resources and services which put the user’s data and privacy at risk. Therefore it’s a top priority to ensure that XSS countermeasures are implemented in your web applications and that custom plugins are carefully designed.







Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »