Replacing addJavascriptInterface() with HTML Message Channels

One item in Google’s app security checklist caught my eye late last week:

WebViews do not use addJavaScriptInterface() with untrusted content.

On Android M and above, HTML message channels can be used instead.

I had glossed over HTML message channels back in my Android 6.0 “random musings” post, and I was somewhat at a loss as to how to use them to replace addJavascriptInterface().

Fortunately, Diego Torres Milano came to my rescue, pointing out a CTS test case for these APIs. From there, I was able to figure out how this stuff works, more or less.

The classic ways we have used to bridge Java and JavaScript, in the context of a WebView, are:

• loadUrl("javascript:...") and evaluateJavascript(), to have Java invoke JavaScript code

• addJavascriptInterface() to expose a Java object as a notional JavaScript global, so that JavaScript can call methods exposed on that object

The latter has been the source of many security bugs over the years, which presumably is why Google is counseling against it.

HTML message channels are a viable alternative, for cases where you control the Web content being shown in the WebView.

postWebMessage() is a method on WebView that allows you to send over an arbitrary string to the JavaScript code in the currently loaded Web page. To receive it, though, the JavaScript must have registered a global onmessage function. So, postWebMessage(new WebMessage("Hi"), ...) will cause the following onmessage function to be called, with e.data being "Hi":

onmessage = function (e) {
  parse(e.data);
}

This can serve as a replacement for loadUrl() and evaluateJavascript(), for Java telling the JavaScript in the current Web page to do something… if and only if the JavaScript is set up to listen to those messages.

Replacing addJavascriptInterface() is substantially more involved, including:

• Calling createWebMessageChannel() on the WebView, to get a WebMessagePort pair representing a communications channel

• Passing one of those ports to JavaScript via postWebMessage()

• Each side, as needed, registering handlers to listen for messages on those ports

• Each side, as needed, sending messages to the other side via those ports

My Stack Overflow answer has a bit more detail. This sample app shows it in use, and I’ll be covering this in greater detail in the next update to The Busy Coder’s Guide to Android Development.

There are some limitations, though:

• You have to modify the JavaScript code to work with these message ports, which should not be a huge issue, given that you had to modify the JavaScript to talk to your injected notional JavaScript global from addJavascriptInterface()

• A bug or undocumented limitation requires you to use loadDataWithBaseURL() and an http or https URL to make this work. You cannot, for example, use this with loadUrl("file:///android_asset/..."), which confused the heck out of me when I was trying to go that route in the sample app.

• This is only available on Android 6.0+, which means until your minSdkVersion is 23 or higher, you have to use the other APIs as well, at least for the older devices that you are supporting.

Is this more secure than addJavascriptInterface()? Probably, insofar as the scope of the API that you expose from Java to the JavaScript code is more intentional. It is more difficult to accidentally expose something when it is more difficult for you to expose anything. However, neither HTML message channels nor addJavascriptInterface() are great solutions for when you are working with arbitrary HTML/JS that you did not write.