Android Webview - Security Mitigation

According to Android security incident handlers, Google will no longer be providing security patches for vulnerabilities that affect versions of Android's native WebView prior to Android KitKat 4.41,2,3.  Google replaced WebView, based on WebKit, with a more recent Chromium-based version of WebView in KitKat OS version.  As a result of the change, Jelly Bean (versions 4.0 through 4.3) and earlier will no longer receive security patches for WebView from Google. All other pre-KitKat components will continue to receive back-ported patches.


All operating systems/platforms (iOS, Windows Phone, Android) continually undergo security updates.  Updates can come in the form of minor patches to major OS revisions depending on specific change(s) required.  While the current vulnerability is not yet disclosed, Rapid7, quoted in the references, discovered several prior attacks on WebView. These previous attacks are from malicious applications via JavaScript code and may provide privilege escalation to the malicious application.  These attack targets the Android browser, based on WebView, in Android Jelly Bean releases prior to 4.3.  Newer Android releases are based on the Chromium browser are not vulnerable.


Customers on pre-KitKat can take a "defense in depth" approach to mitigate the risk of these types of attacks. As the primary attack vector is thru a web-browser and since the end user could accidentally or maliciously go to an infected web site, the primary defense is to block access to the web browser application if not required. The Zebra Enterprise Home Screen Utility4 or MX App Manager feature5 can be used to block access to the browser application.  If access to the browser is required, we recommend using a firewall/proxy to restrict access to authorized sites only and disable JavaScript within the browser.


If you are developing /deploying applications that are built using an HTML5 cross platform development tool such as RhoMobile or PhoneGap, which use WebView for rendering, the risks can be mitigated as developers should confirm that only trusted content (e.g. loaded from a local source or over HTTPS) is displayed within WebViews in their application.  We also recommend that applications written with a cross platform framework are coded to a secure standard and do not expose methods, such as an address bar, that allow users to access arbitrary websites as the sites may contain malicious code6.  

HTML5 applications regardless of deployment can still have the same vulnerabilities as web applications (SQL injection, cross-site scripting, weak encryption, business logic attacks, etc.). HTML techniques overall would not be an issue if the app is coded to a secure standard and there are a ton of best practices around that. In developing in an HTML5 environment one must consider all web application vulnerabilities as well as a number of other key threats.

For our consideration, especially considering WebView (either with the Native view or when called via a cross-platform tool like RhoMobile), our primary concern is really around JavaScript, of which there are four DOM techniques which we recommend avoiding in a modern app:

• eval()

• document.write()

• appendChild()

• innerHTML/outerHTML

All of these methods evaluate a string and turn it into DOM elements. They should never be used for this very reason (with the exception of appendChild, which is secure as long as innerHTML/outerHTML hasn’t been used to make the DOM element). These JavaScript functions allow code to run in dynamic fashion and if the parameters can be manipulated based on user inputs, then using these functions make the webpage vulnerable to Cross Site Scripting and other attacks.

Bottom line, the resolution to these vectors is to inspect and sanitize within the application – especially those that use Webview.


Zebra continuously monitors numerous vulnerability reporting sources ensuring continuous monitoring for all devices we produce.  If and when a vulnerability is discovered in a pre-KitKat version of WebView, Zebra will review the scenarios to determine if an exploit is possible taking into account the variety of security controls our devices employ.  If an exploit could result in negative consequences, Zebra will recommend remediation approaches and/or patch the affected components to remove the vulnerability.


Patches can be sourced, not only from Google, but other open source distributions.  Zebra also can develop the patch using our own talented Zebra developers which was the case with the Heartbleed bug where Zebra produced a patch for our customers in advance of a patch being made generally available. Zebra develops on top of Android Open Source Platform, moving our architecture forward in the most ‘enterprise-focused’ light, with security at the forefront. 


  1. Google stops providing patches for pre-KitKat WebView, abandons 930 million users
  2. Google No Longer Provides Patches for WebView Jelly Bean and Prior
  3. Google Under Fire For Quietly Killing Critical Android Security Updates For Nearly One Billion