How Java Compares on Security

The Java platform has it substantially easier than Microsoft does when it comes to implementing security: Java can be excused if the underlying OS (often Windows) has vulnerabilities. But once you move to the virtual machine, language, and applications, the vulnerabilities are remarkably similar. This is at least partly because both Java and the .NET platform manage the execution activities of the application code employing them. Security holes come primarily from application architectures, rather than from the language itself.

For example, JavaServer Pages (JSP) and J2EE applications running on a Servlet engine or application server are just as susceptible to cross-site scripting attacks as IIS-based ones. The problem is caused not by an inherent flaw in the platform, but by invalidated input. Poor design and implementation practices can defeat platform security mechanisms, regardless of the platform.

It is difficult to assess the Java runtime in comparison to Microsoft's because so many factors come into play. At a high level, both platforms use a similar sandbox security model, which offers roughly the same protections to applications. If there is an edge right now, it probably goes to Java, simply because it has been around longer than .NET and has had a correspondingly greater chance of having its weaknesses found, probed, and addressed.

A few security vulnerabilities have been found in the Java runtime. I expect similar discoveries to be found in Microsoft's .NET Framework, as time goes by. But in and of itself, that slim advantage isn't enough to favor Java over .NET. Ultimately, I'd call security a draw when comparing .NET and Java platforms.