Is client-side java intrinsically less secure than javascript?

Question

Much has been made of a series of bugs and exploits on client side java, leading to the blacklisting of various versions by apple, mozilla, etc. Yet javascript is an even less controlled language without static typing. Today javascript allows for many of the same potential problems: local storage, accessing data in different windows, opening connections to servers (though not arbitrary sockets).

Is it simply that javascript is better tested, with a community including many browser vendors, is it that javascript is somewhat more limited, without sockets for example, or is javascript, in fact, just as vulnerable as java?

Answer 1

It's not a matter of language. It's a matter of environment.

Running Java applets on a web page currently involves using a Java plug-in, which takes a JVM that includes features to do all kinds of things we wouldn't want a web page to be able to do and runs code in that JVM in a "sandbox" to prevent it doing those things. The JVM still has the features, the environment (the plugin) just tries to deny access to them, and the browser has to fully trust the plugin to do that, as it has no control over what the plugin does once it loads it. (This is the nature of NPAPI plugins.) There's been a history of the plugin's sandbox being compromised, and to make matters worse, the update process was clunky and users tended not to keep up with security patches. Since it seems like it's the browser's fault when the plugin gets compromised (it isn't), browser vendors are trying to phase out Java in the browser. Google also claims that their latest architecture for Chrome makes supporting NPAPI difficult.

In contrast, running JavaScript on a web page involves the browser running JavaScript code in its own embedded environment that it (the browser) has full control over, giving it strictly limited access to a small number of browser-controlled features designed from the start (in the case of the modern features) to deny malicious use. The "attack surface" (as security folks put it) is dramatically reduced, and responding to those attacks is fairly directly under the browser vendor's control. You can see how browser vendors would prefer that scenario.

Browsers can be compromised too, of course, which is why browser vendors push so hard to get us to accept automatic updates.

---

Side note: It would have been entirely possible for browser vendors to build a designed-for-security-from-the-start, limited-subset JVM directly into the browser, just as they've built a JavaScript VM into them (through the V8, SpiderMonkey, etc. projects), and have the same degree of control over it. They just didn't. Instead, they focussed on taking JavaScript forward.