Differences with native implementation about react-native-html-webview

[almost]

The rest of the app should be safe from any code running within a webview, there's no way for the webview to communicate with the RN code outside unless you build it. However, often even allowing the attacker to take complete control of the webview could be bad, you may be allowing the webview to communicate back up with the RN app in ways you wouldn't want an attacker to have arbitrary control over. You may also be displaying the webview in such a way that an attacker with control of it could make it seem like your app was doing things (maybe asking for passwords) when in fact the code running in the webview was doing that. Finally, there are sometimes vulnerabilities found in iOS and Android, at least with web browsers the user has to actually visit the page controlled by the attacker (or a page containing an ad controlled by the attacker :( ) for something bad to happen, but depending on how you're using the webview it may be possible to force content in it remotely (for example I'm using this for an email client, so anyone can send an HTML email and have it displayed which would be very bad if there were a way of exploiting browser vulnerabilities).

[almost]

One of the differences was that I supported setting html as a string, they added that though :)

Remaining differences:

• Links clicks don't cause it to navigate away, they just pass the url to the onLink callback
• autoHeight option disables scrolling and sets the height of the view to the height of its contents (this is useful when it's already in a scrollview along with other components)
• Build in HTML sanitization (removes tags and attributes not in a whitelist, including all scripts)

Basically it's aimed at a use case where you want to render some (possibly untrusted) HTML in your app. Probably at some point it will be possibly to lose the custom Objective C bit and use the stock React Native webview underneath.

[IanVS]

Now that you're recommending on your README for people to use <WebView>, does that mean that the differences you've mentioned above no longer apply?

[almost]

The bundled webview can't do those things out of the box but it's now got the capability to add them fairly easily I think. And since including a library that adds native code is a pain I think it's probably worth doing that. I might re-release this library as a wrapper round the built in WebView sometime soon.

[sunny-g]

@almost Slightly tangential question stemming from my not understanding the RN security model: what's the worst that could happen if you execute untrusted JS within this module? Is it that the scripts within the page would run in the same environment as your RN code?

If so, in general, what's the harm in running arbitrary JS within a RN webview? How would that be any more dangerous than navigating to a malicious page in Safari?

[almost]

Yikes, sorry for the wall of text! I need to use more paragraphs :)

[sunny-g]

@almost thanks for the rigorous response!

So to make sure I understand correctly, in summary, the only real risks to my RN app are:

1. the webview could mimic my app, tricking users into provided data in the malicious webview
2. the webview could trigger unexpected behavior in the RN app if the message-passing system I write isn't robust or limited enough
3. general security issues with the webview itself

Is that about right? Thanks again for that breakdown!

[almost]

Yes, thanks, that's a good summary!